セキュリティ

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設定がいくつかあります。

カスタムアプリケーションは、公開アプリケーションと未公開アプリケーションという2つのカテゴリに分類されます。公開アプリケーションは、Box統合にあります。Box管理者は、公開アプリケーションと未公開アプリケーションをデフォルトで有効にすることによって、承認なしで使用できるようにするかどうかを決定できます。これらの設定のステータスにより、使用するアプリケーションを問題なく承認するために必要な操作が決まります。

上記の設定に関係なく、JWTまたはクライアント資格情報許可を利用するアプリケーションを企業で使用するために、管理者はBox管理コンソールでそのアプリケーションを明示的に承認する必要があります。承認は特定時点でのスナップショットです。つまり、開発者が開発者コンソールに再度アクセスして構成を変更した場合、管理者は、生成されたアクセストークンにその変更を反映するためにアプリケーションを再承認する必要があります。

[デフォルトで未公開アプリを無効にする] の設定をオンにした場合、管理者は、認証方法としてOAuth 2.0を利用しているアプリケーションを明示的に有効にする必要もあります。

また、この設定をオンにした場合は、サーバー認証アプリの有効化も必要になります。