セキュリティ

Box API を使い始めたばかりの開発者でも、アプリケーションの承認を担当する Box 管理者でも、Box に保存されたコンテンツを保護するためにセキュリティメカニズムを理解することは非常に重要です。 Box API は、Box ウェブアプリと同じセキュリティの原則と制限に従います。つまり、Box API を利用しても、コンテンツの権限、ウォーターフォール型のフォルダ構造、または管理者向けの要件を回避することはできません。

​

アクセストークン

さまざまな Box API コールの中核となるのはアクセストークンです。ユーザー名とパスワードは使用できないため、Box サーバーにはユーザーの本人確認を行う手段が必要になります。アクセストークンの全機能には、ユーザーの権限、トークンの権限、アプリケーションの設定が含まれます。 アクセストークンは認証済みのユーザーを表し、ユーザーが問題なく呼び出すことができるコンテンツを決定します。Box ウェブアプリを使用する場合と同様に、問題なく操作できるのは、アクセストークンに関連付けられたユーザーが所有するコンテンツまたはコラボレータとなっているコンテンツのみです。これは、トークンのダウンスコープによってさらに制限できます。 アクセストークンの有効期限は 60 分のみですが、必要に応じてそれより前に取り消すことができます。アクセストークンの有効期限が切れると、OAuth 2.0 アプリケーションを使用している場合、更新トークンを別のアクセストークンと交換できます。更新トークンは、60 日後または 1 回の使用後に有効期限が切れます。また、サーバー認証アプリケーションを使用している場合は、新しいアクセストークンを得るためにアクセストークンをリクエストエンドポイントを呼び出す必要があります。セキュリティ上の理由により、Box では有効期間の長いアクセストークンを許可していません。

​

スコープ

スコープは、アプリケーションの作成時に開発者コンソールで構成されます。スコープにより、150 を超えるエンドポイントのうち、アプリケーションが問題なく呼び出せるものが決まります。 スコープはユーザーの権限と連動しているため、書き込みスコープを付与しても、ユーザーは、Box Enterprise のすべてのコンテンツに自動的にアクセスできるわけではありません。つまり、認証済みユーザーは、アクセス権限を持つコンテンツに対する書き込み呼び出しを実行したときに、成功を示す API レスポンスを受け取ることができます。 たとえば、ユーザーの管理およびグループの管理のスコープだけが有効になっているアプリケーションを考えてみましょう。このアプリケーションのアクセストークンがフォルダの情報を取得する API コールを実行しようとすると、関連付けられているユーザーがそのフォルダを所有している場合でも、403 エラーが返されます。これは、この操作を実行するには読み取りスコープが必要なためです。このアプリケーションのアクセストークンには、ユーザーおよびグループに関連した API コールに対してのみ、成功を示すレスポンスが返されます。

​

制限されたエンドポイント

適切な権限を付与された管理者または共同管理者のみが問題なく使用できる API エンドポイントがいくつかあります。原則として、管理者または共同管理者だけが Box 管理コンソールで実行できる操作の場合、その操作の API コールを完了するには、これらのユーザーのいずれかに関連付けられたアクセストークンが必要になります。これについては、必要に応じて、特定のエンドポイントに関する APIリファレンスのドキュメントを参照してください。 管理者に制限されたエンドポイントの一部を以下に示します。

• ユーザーの作成、削除、またはその情報の取得
• グループの作成、削除、または変更
• ユーザーまたは企業のイベントの表示

企業で Box Governance や Box Shield などのアドオン製品を購入している場合は、以下のように、管理者ユーザーのアクセストークンでのみ使用できるエンドポイントが他にもあります。

• セキュリティ分類の操作
• リーガルホールドポリシーと割り当ての操作
• リテンションポリシーと割り当ての操作

​

アプリケーションアクセス

サーバー認証 (JWT使用) またはクライアント資格情報許可を利用するアプリケーションのアプリケーションアクセスは、開発者コンソールでのみ構成できます。この設定により、アプリケーションで使用できるユーザーのタイプが決まります。[アプリアクセスのみ] と [アプリ + Enterprise アクセス] という 2 つのオプションがあります。 Box 管理コンソールでこれらのアプリケーションのいずれかを承認すると、そのアプリケーションを表すサービスアカウント (AutomationUser_xxxx_@boxdevedition.com) が自動的に生成されます。このアカウントは管理者に似たユーザーで、API を介してしかアクセスできません。その後、このユーザーを使用して、App Userと呼ばれる、アプリケーションのユーザーを作成することができます。サービスアカウントと App User しか操作する必要がないアプリケーションの場合は、[アプリアクセスのみ] を選択します。管理対象ユーザーとその既存の Box コンテンツを操作する必要があるアプリケーションの場合は、[アプリ + Enterprise アクセス] を選択します。 たとえば、読み取り/書き込みスコープと [アプリアクセスのみ] が指定された JWT アプリケーションが管理コンソールで適切に承認されているとします。管理対象ユーザーがアクセストークンを取得し、自分が所有するフォルダに対して API コールを実行すると、「Cannot obtain token based on the enterprise configuration for your app (アプリに対する Enterprise の構成に基づきトークンを取得できません)」というメッセージとともに 400 エラーが返されます。ユーザーにコンテンツへのアクセス権限があり、適切なスコープが有効になっていて、アプリが承認されていても、選択したアプリケーションアクセスで許可されるのは、アプリケーションによるサービスアカウントと App User の操作のみです。

​

Enterprise 設定と承認

Box API に関して言えば、注意すべき Enterprise 設定がいくつかあります。 Platform アプリケーションは、公開アプリケーションと未公開アプリケーションという 2 つのカテゴリに分類されます。公開アプリケーションは、Box 統合に表示されます。Box 管理者は、公開アプリケーションと未公開アプリケーションをデフォルトで有効にすることによって、承認なしで使用できるようにするかどうかを決定できます。これらの設定のステータスにより、使用するアプリケーションを問題なく承認するために必要な操作が決まります。 上記の設定に関係なく、JWTまたはクライアント資格情報許可を利用するアプリケーションを企業で使用するために、管理者は Box 管理コンソールでそのアプリケーションを明示的に承認する必要があります。承認は特定時点でのスナップショットです。つまり、開発者が開発者コンソールに再度アクセスして構成を変更した場合、管理者は、生成されたアクセストークンにその変更を反映するためにアプリケーションを再承認する必要があります。 [デフォルトで未公開アプリを無効にする] の設定をオンにした場合、管理者は、認証方法としてOAuth 2.0を利用しているアプリケーションを明示的に有効にする必要もあります。 また、この設定をオンにした場合は、サーバー認証アプリの有効化も必要になります。