セキュリティ

モバイルアプリの価値が上がるにつれて、セキュリティへの配慮も重要になります。

Kii Cloud は、仕様がオープンなシステムであるため、アプリケーションのアクセスキー（AppID）を入手した攻撃者はアプリケーションを偽装して Kii Cloud にアクセスできます。ただし、これはユーザーデータが漏洩することを意味しません。正しいアクセス制御で守られている限り、たとえアクセスキーが漏洩したとしても、ユーザーデータの改ざんなどは未然に防ぐことが出来ます。

一方で、管理者用のアクセスキーを入手した攻撃者は、管理者機能によりすべてのユーザーのデータを読み書き可能となります。このため、この情報は第三者に漏洩しないよう厳重に管理することが肝要です。

以下では、これらのセキュリティに関するトピックを解説します。モバイルアプリを設計するときは、こうした脅威を様々な側面から検証し、Kii Cloud のセキュリティ機能を適切に使用することでデータを保護するようにしてください。

アクセスキーの漏洩とリスク

前述のように、クラウドへのアクセスキー（Kii Cloud の AppID）があると、モバイルアプリからのアクセスと同じことが容易にできてしまいます。

AppID は、モバイルアプリにインストールされている実行ファイルを逆コンパイルしたり、クライアントにダウンロードされた JavaScript のファイルを参照したりすることで比較的容易に取得できます。攻撃者がこれらの手段でアクセスキーを入手すると、REST の仕様に沿った呼び出しを行うだけで、モバイルアプリと同じ操作ができます。

ただし、たとえアクセスキーが漏洩したとしても、ユーザーのパスワードが漏洩することはありません。このため、適切なアクセス権で守られたアプリケーションデータが攻撃者に漏洩することはありません。

• ユーザースコープのデータは、デフォルトのアクセス権設定ではこのユーザーのみアクセス可能です。このため、該当ユーザーのパスワードを知らない攻撃者はアクセスできません。

• グループスコープのデータは、デフォルトのアクセス権設定ではこのグループに属するユーザーのみアクセス可能です。このため、該当ユーザーのパスワードを知らない攻撃者はアクセスできません。

つまり、たとえ AppID が知られてしまっても、ユーザースコープとグループスコープのデータについては、各ユーザーのパスワードが別のルートで漏洩しない限り安全であるといえます。

アプリケーションスコープのデータ

アプリケーションスコープのデータは、デフォルトではログインしているすべてのユーザーから読み書きできる点に注意が必要です。これは、モバイルアプリだけでなく、攻撃者も読み書きができることを意味します。なぜなら、攻撃者は AppID を元に任意のユーザーを作成し、そのユーザーを使ってアプリケーションスコープのデータを自由に読み書きできるためです。

たとえば、アプリケーションスコープにゲームのハイスコアを置く場合、モバイルアプリから直接ハイスコアを書き込むような設計にしてしまうと、攻撃者から容易に書き換えられるリスクが生じます。

この問題に対する根本的な解決は難しいですが、ロジックの不明瞭さによるセキュリティによって、直接的な書き換えのリスクを避けることだけでも対処しておくべきと考えられます。たとえば、以下のような方法を検討します。

• アプリケーションスコープから認証済みユーザーの書き込み権を削除し、特定ユーザーからの書き込み権を与えます（管理者アカウントを使って ACL から認証済みユーザーの権限を削除します）。

• サーバー機能拡張を使って、書き込み可能なユーザーの権限でハイスコアデータを書き換えられるようにします。

• ハイスコアを書き換えるときは、サーバー機能拡張にリクエストします。このとき、ハイスコアの根拠となるゲーム内の状態データをパラメータで指定するなどの工夫をします。ゲーム内の状態データが攻撃者にとって分かりにくいことがセキュリティを保持できる根拠となります。

  

管理者用のアクセスキーの漏洩とリスク

Kii Cloud では管理者権限でアクセスできる ClientID と ClientSecret があります。これらの値があれば、管理者機能によりすべてのユーザーのデータを読み書きできます。すなわち、一旦 ClientID と ClientSecret が攻撃者の手に渡ってしまえば、攻撃者はアプリケーションのすべての情報を自由に読み書きできるようになり、あなたのサービスは成り立たなくなります。

このため ClientID と ClientSecret は、モバイルアプリに含めて配布してはいけません。もし、これらがダウンロード可能なコード上に存在していると、攻撃者は解析によってこれらの値を手に入れることができます。たとえ ClientID と ClientSecret を暗号化してコードに埋め込んだとしても、プログラムから復号して参照できるということは、攻撃者も同じ方法で復号し、取得することができます。

もし、モバイルアプリから管理者機能を使いたい場合は、サーバー機能拡張を使うようにします。サーバー機能拡張のプログラムは Kii Cloud 上で管理され、アプリケーションの管理者だけがアクセスできます。設計上、攻撃者はプログラムを取得することができないため、ClientID と ClientSecret が埋め込まれていても攻撃に対するリスクは低いものとなります。また、こちらのサンプルコード のように、通常はサーバー機能拡張の機能を使って直接管理者トークンを扱えるため、ClientID と ClientSecret をプログラムに埋め込む必要もありません。

漏洩した場合

ClientID と ClientSecret が外部に漏洩した可能性がある場合は、ただちに 開発者ポータルで ClientSecret をリセット してください。

リセットを行うと、現在の ClientSecret は無効化され、新しい ClientSecret が払い出されます。なお、セキュリティ担保の観点から、リセット前に発行されていた全ての アクセストークン は、ClientSecret のリセットと共に無効化されます。

ロジックの不明瞭さに頼る脆弱性

Kii Cloud による開発に限った話ではありませんが、攻撃者からの不正なアクセスを防ぐ方法として、ロジックが攻撃者に分からないことだけを安全性の根拠にするのは避けるべきです。ロジックを分かりにくくして秘密の情報を隠すことはよく行われますが、攻撃者は時間をかけて分かりにくいロジックを解析することができます。特に、モバイルアプリのように、実行可能コードがユーザーの元にダウンロードされるコンポーネントは、逆コンパイルが可能であるため、解析されるのは時間の問題と認識すべきです。

攻撃の例として、ユーザー名とパスワードを入力せずに Kii Cloud を使用するモバイルアプリを考えます。このアプリでは、乱数でユーザー名を生成し、そのユーザー名を暗号化したものをパスワードにするとします。

この場合、暗号化の方法が不明瞭であることによりセキュリティを確保しているといえます。攻撃者は、モバイルアプリの実行コードを解析し、パスワードの生成方法を突き止めることができます。こうなると、攻撃者は他人のユーザー名だけでそのユーザースコープとグループスコープの Bucket を自由に読み書きできるようになります。

たとえ、暗号化ロジックを複雑で独自のものにしても、不明瞭さが増したことで攻撃者の作業が難しくなるだけで、そのロジックはいつか読み取られることを覚悟しておく必要があります。ロジックの不明瞭さはセキュリティを確保する手段の 1 つといえますが、それだけでセキュリティを確保するのは不完全かつ危険です。

この例では、パスワードも乱数で作り出すのが解決の方法です。生成したユーザー名とパスワードをデバイスのストレージに保存しておきます。攻撃者は、ロジックをすべて知っていたとしても、ユーザー名とパスワードにアクセスできない限り、Kii Cloud のデータは読み書きできません。ストレージからの読み込みは書き込んだモバイルアプリからしかできないため、セキュリティを確保できます。