Monacaには連携サービスの一つとして、ニフクラ mobile backend（以下NCMB）があります。

プッシュ通知などで使った経験がある方もいるのではないでしょうか？

NCMBは、「アプリケーションキー」と「クライアントキー」という、2つのキーを使ってAPIアクセスを行います。

この時心配になるのは、キーをどう扱うかではないでしょうか？

この記事では、NCMBのエバンジェリストを務めている私の経験を踏まえて、キーをどういったものとして考えるか、どうアプリのデータをセキュアに保つかについて解説します。

鍵(キー)の役割

まずアプリケーションキー、クライアントキーのそれぞれの役割について紹介します。

アプリケーションキーは、あなたのMonacaアプリが、NCMBにおけるどのアプリケーションにアクセスするかを特定する情報です。

クライアントキーは、NCMBにアクセスする際に不正なアクセスではないことを証明するための署名を生成するのに利用します。

署名はリクエストデータやタイムスタンプなどとともに、クライアントキーでハッシュ値を作成します。

この2つのキーがないとMonacaアプリからNCMBへのアクセスはできません。

鍵(キー)が漏洩した場合に起きることと対策

アプリケーションキーとクライアントキーが漏洩した場合、悪意を持ったユーザーはそのキーを使ってNCMBにリクエストを送れるようになります。

ここでは、NCMBの主な機能ごとに、キーが漏洩した場合に起こることと、それに対する対策を紹介します。

NCMBの主な機能として、以下が挙げられます。

  • データストア（クラウドデータベース）
  • ファイルストア（ファイルストレージ）
  • 会員管理（認証）
  • プッシュ通知
  • スクリプト

データストア

データストアへの不正なデータ追加や、データ削除を恐れる方は多いでしょう。

しかし、NCMBにはACL（アクセス権限）機能があり、適切な権限管理を行うことで不用意なデータ取得や更新、削除は防止できます。

アクセス権限を使うためには認証が必要ですが、NCMBではID/パスワードを使わない匿名認証機能もあります。この匿名認証機能を用いれば、ログインやユーザー登録機能を実装することなく、アクセス権限が利用できます。

2つ目に不正なアクセスによって、不要なカラムを追加される可能性があります。

しかし、データのCRUD操作はもちろん、カラムの追加などについてはクラス（一般的なデータベースでいうテーブル相当）ごとに権限を指定できます。管理者グループのみカラムを追加できるといった設定にしておけば、そうした不正な操作を防止できます。

3つ目に不正なクラスを追加される可能性です。

これは管理画面にて、クラスの追加を無効にすることで防止できます。本番運用時には設定しておきましょう。

ファイルストア

ファイルストアについては不正なファイルアップロードが想定されます。

ファイルの削除、差し替えについてはACL（アクセス権限）で防止しましょう。

また、ファイルアップロードについても特定の権限を持ったユーザーだけに絞った設定ができます。こちらも予期せぬファイルをアップロードされないように、本番運用時には設定しておきましょう。

なお、NCMBでは無料ユーザーが1ファイル5MB、有償ユーザーは1ファイル100MBまでアップロードできます。大きなファイルがアップロードされると困る場合には、クライアントサイドで制御する方が良いでしょう。

会員管理（認証）

会員データはデフォルトで本人のみ閲覧、更新できる権限となっています。

また、パスワードは管理画面からも閲覧されません。そのため、本人がパスワードが漏洩したり、ソーシャル認証側で不正アクセスが発生しない限り、ユーザーデータは安全です。

設定でユーザーデータへの読み込み権限を付けることもできます。場合によっては必要でしょうが、その場合には管理画面にて「会員管理 SNS認証データ」設定を含めないようにしてください（ソーシャル認証を使っている場合）。AuthDataフィールドにはソーシャルサービスの認証に利用するデータが含まれますので、ユーザーデータ閲覧時に認証データが送られてしまいます。

プッシュ通知

アプリケーションキーとクライアントキーがあることで、プッシュ通知を不正に作成できる可能性があります。

これを防ぐためには、NCMB管理画面にて「SDKからの操作」を許可しない設定にしてください。SDKからプッシュ通知は作成できなくなりますが、管理画面からは作成できます。運用次第ではありますが、SDKからプッシュ通知を作成していないのであれば、ぜひ設定してください。

スクリプト

スクリプト機能は任意のJavaScript/Rubyスクリプトをアップロードして、クラウド上で実行する機能です。これはコードの内容が分からない限り、不正に利用されるケースは多くないでしょう。スクリプト側で独自に認証させることもできます（独自のヘッダーを用いるなど）。また、スクリプトについてもACL（アクセス権限）が設定できますので、特定の権限を持ったユーザーのみ実行できるなどと指定できます。

鍵(キー)を安全に保つには

ここまではキーが漏洩した場合に起こることと、それに対する対策を紹介しました。

ではキーをMonacaアプリの中で安全に保つにはどうしたら良いかを考えてみます。

クラウドから取得する

NCMBにはファイルストアにアップロードしたファイルをHTTP取得する機能があります。この時には認証はいりません。これを使ってアプリケーションキーとクライアントキーの2つをJSONファイルなどで保存しておき、アプリから取得する仕組みが考えられます。

もちろんJSONファイルには平文でキーが記述されていますので、ネットワーク通信の内容を見られればキーが分かってしまうかも知れません。さらに暗号化Zipファイルにして、Monacaアプリ上で解凍するといった仕組みにすることもできます。

この場合の利点は、万一キーが漏洩した場合に管理画面でキーを再生成し、ファイルストアのファイルを差し替えるだけで済むことでしょう。アプリのビルドや、審査が不要になるのが利点です。

欠点は、アプリ起動時に1回だけですが、APIアクセスが増えてしまうことでしょう。

アプリ全体を暗号化する

Monacaではアプリロジック暗号化 (Encrypt プラグイン)を提供しています。

このプラグインを使うことで、アプリロジック全体を暗号化でき、アプリケーションキーなども暗号化されます。実際、アプリケーションキーだけでなくアプリのロジック（JavaScriptコード）も漏洩すると問題がありますので、アプリ全体の暗号化はお勧めです。

クラスのパーミッション・アクセス権限を適切に設定する

これまで記述した通り、キーが漏洩したとしても、アクセス権限を適切に設定することで不正利用は十分に防止できます。

管理画面から任意のクラスを作成されないように設定したり、SDKからプッシュ通知を作成されないように設定すれば、セキュアになります。

Monacaプラグインを開発する

クライアントキーを返すCordovaプラグインを開発すれば、キーをコンパイルされた状態にできます。一方、アプリケーションキーはリクエストヘッダーを見れば分かるので、隠す意味は特にないでしょう。ただし、Android向けのコードは中間コードとして生成されるので、コードを復元できる可能性があります。

まとめ

NCMBのキーが漏洩しないのがベストではありますが、完璧に防ぐのは難しいです。しかし、適切な設定とコードを書くことで、キーが漏洩したとしても安全にアプリを提供できます。

肝になるのはデータへのアクセス権限と管理画面での設定になります。

あなたのアプリを安全に提供するためにも、ぜひ適切な設定を行ってください。