セキュリティチームの ぐっちー です。Boxでは上位で付与されたアクセス権限を下位で消すことはできませんが、 ”Can_view_Path” というパラメータを使って、アクセス権限を消している「ように」見せる方法についてご紹介します。
- 本ブログの内容は、2023年11月7日時点までの情報を元に作成しております。
- 実際には、下位のフォルダに招待しつつ、「Can_view_Path」という設定で親パスを見せているだけです。ただ、ユーザー体験としてアクセス権限を消している「ように」見せることも可能だという話をしています。
3行サマリー
- Boxでは上位で付与されたアクセス権限を下位で消すことはできません。
- 一方で、Box APIで利用する「Can_view_Path」という設定を使用することで、上位で付与された権限を消している「ように」見せることができます。（実際には、下位のフォルダに招待しつつ、「Can_view_Path」という設定で親パスを見せているだけ）
- この方法を使って運用していくには、ワークフロー等での効率化をしないと情シスがキツくなってしまったり、運用がカオス化することが考えられるため、基本はアクセス権限を下位で消している「ように」見せない運用の方がおすすめです。
- どうしても実施したい場合の効率化の話に関しては別ブログで書きたいと思います。
上位で付与されたアクセス権限は下位で消せない
Boxのフォルダ設計のよくあるパターンとして、例えば各種プロジェクトに関する情報を格納するフォルダを作成する際、管理者は「プロジェクトフォルダ」というトップレベルフォルダを作成し、プロジェクトA、B、Cなどの下層フォルダを作成するのがよくあるパターンです。
この場合において、可能であればトップレベルフォルダにユーザーやグループを招待し、下位のフォルダに対しては権限の継承でアクセスを許可するというスタイルがアクセス権限のメンテナンスや運用上好ましい形となります。ユーザーとしては[プロジェクトフォルダ] > [Aプロジェクト] という風にツリーを伝っていくことで目的の情報にアクセスできます。
一方で、上記の構成の前提条件はこの構成が取れるのは、アクセス権が必要なプロジェクト以外にもアクセス権を持っても構わない場合です。そのため、自分のアサインされているプロジェクト以外へのアクセスを許可されていない場合に難しい状況となります。この場合、上位で付与されたアクセス権限は下位では消すことができないという性質があるため、2階層目の各プロジェクトフォルダに個別でユーザーにアクセス権を割り当てるか、違うフォルダツリーにアクセス権を厳重にしければならないフォルダを外出しするかという手法を取ることになります。
これを行うとユーザー目線では下記のイメージ画像のように、トップレベルに複数のプロジェクトフォルダが存在するように見えます。これはユーザーにとっては見にくいと感じるケースがあり、解消できないかとお客様から多くの相談を受けることがあります。
BoxのCan_view_Pathで上位で付与されたアクセス権限を下位で消している「ように」見せる
この時1番最初に想像するソリューションは「上位で付与された権限を下位で消す」という点です。しかしながら、Boxでは上位で付与された権限を下位で消すことはできません。そこで、Box APIの「Can_view_Path」という設定を使用することで、上位で付与された権限を消している「ように」見せることができます。「Can_view_Path」はBoxのAPIでコラボレーションを作成する際に使うパラメータの1つです。このパラメータを有効化して招待をすると、ユーザーは招待されたフォルダの親フォルダを表示することができます。
例えば、上記図のようなフォルダ構成を作っている場合で、プロジェクトAとプロジェクトCのみのアクセス権限が必要な場合、プロジェクトAとプロジェクトCにAPIでユーザーを招待し、「Can_view_Path」を有効化してあげることで、プロジェクトAとプロジェクトCのみが見える状態で、親フォルダである「プロジェクトフォルダ」も閲覧可能な状態を作り上げることができます。
設定方法
Boxの開発者コンソールで新規アプリ作成
まず、Boxの開発者コンソールでアプリを作成します。Boxの開発者ポータル（ https://自社のドメイン.app.box.com/developers/console ）にアクセスし、[アプリの新規作成]ボタンをクリックし、[カスタムアプリ] を選択し、認証方法は JWT（サーバー間認証用）を選択して保存します。
Box APIでのユーザー or グループ招待
その後、以下のような形でAPIでリクエストを行います。
curl -i -X POST "https://api.box.com/2.0/collaborations" \
-H "Authorization: Bearer <アクセストークン>" \
-H "Content-Type: application/json" \
-d '{
"item": {
"type": "file",
"id": "<招待したいフォルダのIDを指定>"
},
"accessible_by": {
"type": "<ユーザー（user）かグループ（group）を指定>",
"id": "<ユーザーIDまたはグループIDを指定>"
},
"role": "editor",
"can_view_path": "true"
}'それぞれの値は以下のように設定します。
アクセストークン：
今回は簡易的な検証の立て付けなので、開発者トークン（60分で有効期限切れ）を利用します。開発者トークンは作成したアプリの[構成]にて取得します。
今回のブログでは簡易的に開発者トークン（60分で有効期限切れ）を利用していますが、今後ワークフローを作っていく際には、鍵の管理やアクセストークンの生成などの論点が検討が必要となる点に留意いただけたら幸いです。また、鍵の漏洩には厳重に注意していただけたら幸いです。
招待したいフォルダのID：
招待したいフォルダのfolder/以下の数字がフォルダIDです。
ユーザーID：
ユーザーIDは管理コンソールの[ユーザーとグループ]で確認することができます。
グループID：
管理コンソールから指定のグループにアクセスし、URLのgroup/以下の数字がグループIDです。
動作確認
まずは、管理者（トップレベルフォルダ所有者）からのプロジェクトフォルダ見え方としては以下のように、すべてのフォルダが見えている状況となっています。
一方で、招待されたユーザー側でログインすると、トップレベルに「プロジェクトフォルダ」があるにも関わらず、1階層下の各プロジェクトフォルダには必要なものしかアクセス権限がないような動作となりました。
また、Boxのグループに対しての招待でも「Can_view_Path」が有効に機能していることを確認ができました。
運用どうするか問題が課題
ここまで読んでいただけたらお分かりの通り、ユーザーの招待をAPI経由で個別にやっていかなければならないので、運用が非常に大変です。考えなしにやったら、ユーザーが快適に業務をするために、情シスが泣きながら対応すると言う結末になってしまうと思います。その上で、やはり以下のような運用の検討が必要だと思います。
Boxグループを活用パターン
フォルダへの招待をグループに対して実施し、以後のメンバーのメンテナンスはグループのメンバーのメンテナンスとして実施する方法です。Boxグループの管理者を個別に指定しておくことで、指定されたユーザーはフォルダのアクセス権のコントロールを管理コンソールで行うことができます。
ただし外部コラボレーターはグループに追加できないので、外部コラボレーター招待はAPIで実施するか、Can_view_Pathを諦める形となると思います。まあ、外部コラボレーターであれば、Can_view_Pathがなくても文句を言われなさそうなので、個人的にはフォルダに直接招待してしまっても良い気がしています。
ワークフローパターン
承認ワークフローやiPaaSを使って、Boxのユーザー招待をcan_view_pathを有効にした状態で実施するフローを構築するパターンです。ユーザー等による申請を受けて、管理者が承認し・・・などという流れが考えられますが、その辺の話は別で検証してブログ化したいと思います。当たり前の話ですが、鍵の管理等のトピックを考慮しなければならないため、作り上げるのもそれなりにめんどくさいと思います。
「あれ？この資料見れない」が起きやすい可能性あり
この設定を使ったフォルダ構成は複雑な構成となりやすい性質があると言えます。そのため、アクセス権の付与が追いつかず、「あれ？この資料見れない」という話が起きやすい性質があることが安易に予想されます。そのため、使い所を見定めて利用していただけたら幸いです。
おわりに
運用が大変、かつ煩雑になりそうなので、基本はアクセス権限を下位で消している「ように」見せない運用（普通の運用）の方がおすすめではありそうですが、機微情報を多く取り扱っているケースなど刺さりそうなケースがありましたら活用いただけたら幸いです。
