「Box」運用の落とし穴はココ 担当情シスが引っ掛かるフェーズ別の課題と解決策

クラウドストレージ「Box」の導入から運用で引っ掛かりがちな課題について、A社の実例を通じて導入検討フェーズから運用設計までを詳しく解説する。

[土肥正弘，ドキュメント工房]

　商社系SIerの丸紅ITソリューションズ（丸紅I-DIGIO）は、2018年にクラウドストレージサービス「Box」を全社に展開し、顧客へのBox導入支援を開始した。現在までに400社以上の支援実績を積み重ねている。本稿ではランサムウェア対策をきっかけにBoxを導入した、丸紅I-DIGIOの顧客企業A社の実例を基に、Box活用で陥りやすい課題とその解決策を、導入検討からPoCまでの事例を通じて解説する。

1．Box導入検討フェーズの課題：暴露型ランサムウェアへの対策

2．環境構築フェーズの課題：「外部参照マクロが動かない」への対応法

3．PoCフェーズの課題：Box運用設計での落とし穴と対処法

1．Box導入検討フェーズの課題：暴露型ランサムウェアへの対策

　近ごろのランサムウェアは、「暴露型」や「二重脅迫型」と呼ばれる手口が主流だ。ファイルを暗号化するだけでなく、情報を外部に漏らすと脅迫する手法だ。Boxのバージョン管理機能を使えば暗号化されたファイルを以前の状態に戻せるが、情報漏えいを防ぐにはBoxの標準機能だけでは不十分だ。

　ランサムウェアに感染したPCがデータを勝手にダウンロードすることを防ぐ、もしくはアップロードを制限する必要がある。この課題を解消するのが、Boxのオプション機能「Box Shield」だ。Box Shieldではファイルごとに「一般」や「機密」などのラベルを付けて、ラベルごとにダウンロードの可否を細かく設定できる。

　全てのファイルのダウンロードを禁止すると業務に支障が出るため、「機密」ラベルが付いたファイルだけをダウンロード禁止にし、それ以外のファイルは通常通り使用できるように設定した。

　例えば、「請求先一覧」などの機密情報を含むファイルには機密ラベルを付けてダウンロードを禁止し、手順書のような流出してもリスクが少ないファイルには「一般」ラベルを付けて、ダウンロードを許可する。これにより、万が一大量のファイルを一括でダウンロードされても、機密データの流出を防ぐことが可能だ。

図1　機密ファイルにダウンロード不可のラベルを付与（出典：イベント投影資料のキャプチャー）

　ラベル機能によるダウンロード制御は、社外の協力会社や取引先（外部コラボレーター）にも適用した。社内のユーザーに対しては、Boxの管理コンソールから特定のアプリ（「Box Drive」など）へのアクセスを制限できるが、これは社内の端末に限定された対策だ。

　一方で、外部コラボレーターと共有フォルダを使ってファイルをやりとりしている場合、相手のPCがウイルスに感染していれば、その共有フォルダから攻撃プログラムが実行される恐れがある。だが、Box Shieldのラベル機能を使って機密ファイルにダウンロード禁止設定をしておけば、外部コラボレーターがそのファイルを自分の端末に保存することはできなくなる。これにより、情報漏えいのリスクを低減できる。

図2　外部コラボレータとのBox Driveの利用について（出典：イベント投影資料のキャプチャー）

図3　外部コラボレータとのBox Driveは制限ができない（出典：イベント投影資料のキャプチャー）

2．環境構築フェーズの課題：「外部参照マクロが動かない」の対処

　導入検討フェーズを終え、初期構築フェーズに移行した段階で、Boxにおける外部参照マクロの使い勝手に関する課題が浮上した。これはクラウドストレージ全般に共通する問題であり、Boxでも完全に利用できないわけではないものの、幾つかの制約やデメリットがある。

　まず、ファイルのパスが生成されることでセキュリティリスクが生じる。また、エクスプローラーでフォルダをゴミ箱に移動すると、ユーザーのアクセス権が失われてしまう。さらに、機密ラベルを付けたファイルを別のフォルダにコピーすると、コピー先のフォルダのラベルに上書きされ、機密ファイルとしての管理ができなくなる可能性もある。

　これらの理由から、Boxでの外部参照マクロの利用は基本的に推奨されていない。だが、A社の一部の部署ではどうしても必要だったため、対策が求められた。

　当初はOfficeの共同編集機能を使い、パス名を変更することで外部参照マクロを動作させる方法を検討した。動作自体は確認できたが、常にOfficeのバージョンを最新に保つ必要があり、A社の環境では継続的なアップデートが難しいと判断し断念した。

　そこで次に、Box Driveの制約を踏まえながら一部部署のみで外部参照マクロの利用を許可する方法を模索した。標準の管理コンソールではBox Driveの利用は全社一律で許可か禁止のどちらかだが、「デバイストラストポリシー」を適用すると、特定部署やグループだけに利用を許可できる。これはアクセスする端末にセキュリティ基準を設定し、基準を満たさない端末のアクセスをブロックする仕組みだ。

　これにより、A社は特定グループ内で安全にBox Driveを運用し、外部参照マクロを使用できる環境を整備した。

3．PoCフェーズの課題：Box運用設計での落とし穴と対処法

　これらの検証と運用提案を経て、A社はPoC（概念実証）フェーズに進んだ。PoCでは、Boxに組織フォルダや社内限定フォルダ、社内共有フォルダ、個人フォルダなど複数のフォルダを作成し、利便性と運用性、セキュリティの3つの視点から検証した。その過程で幾つかの課題も見つかった。丸紅I-DIGIOの野間菜月氏が、これらの課題とその解決策を6つのポイントにまとめて解説する。

（1）フォルダ表示だけでは社内限定か社外共有かフォルダの役割が分かりにくい

　PoC対象ユーザーから、自分が閲覧しているフォルダが「社内限定」なのか「社内共有」なのか画面では判別しにくいという指摘があった。あるユーザーは社内共有フォルダ内の打ち合わせフォルダに招待されていたが、上位階層のフォルダパスを確認できず、全ての招待フォルダが青色表示されるため、不安を感じていた。

　これを受けて情報システム部門は当初、フォルダの説明欄を活用する案を検討したが、上位階層の説明がユーザーに伝わりにくいことが分かった。そこで、フォルダ画面の右側に表示されるコラボレーター一覧を活用する方法を提案した。

　この一覧には、上位階層、下位階層にかかわらずコラボレーターのアイコンと名前が表示されるため、ここに「社外共有フォルダ」などの名前とアイコンを設定すれば、ユーザーがフォルダの種類を誤認するのを防げる。グループ名の表示も検討したが、グループアイコンは変更できず分かりにくいため、最終的にコラボレーターのアカウント表示を利用する方法が採用された。

図4　コラボレーター表示を利用してフォルダ階層を明示（出典：イベント投影資料のキャプチャー）

図5　階層をたどってパスが見られない（出典：イベント投影資料のキャプチャー）

（2）フォルダ名の変更を禁止したい（情シスからの要望）

　A社の情報システム部門は、組織フォルダを組織コードや組織名の命名規則に沿って作成し、フォルダ名を変更せず運用するルールを定めていた。だが、ユーザーが善意でフォルダ名の末尾に「試験運用中」などの説明を追加する事態が発生した。

　これは、ユーザーに編集権限があったためで、権限をビュワーやアップローダーに変更すれば名前の変更は防げるが、編集権限をなくすと共有資料の閲覧確認ができなくなるという問題があった。そこで、フォルダ名が変更された際に自動的に元の名前に戻す仕組みを提案した。丸紅I-DIGIOの「Light CASB for Box」というソリューションの機能を活用して実現した。

（3）外部ユーザーを共同所有者にしたくない（情シスからの要望）

　外部ユーザーが共同所有者として招待されるケースも考えられるが、リスクが伴う。そこで、外部ユーザーが共同所有者に招待された場合、自動的に編集者に権限を下げるよう提案した。

　この機能も「Light CASB for Box」によって実現でき、先に挙げた課題（3、4）は、このソリューションの導入だけで解決できた。

（4）広報系コンテンツをまとめて公開したい（広報担当／情シスからの要望）

　広報系コンテンツの公開では、共有リンクに自動で有効期限が設定されるため、不便だという声が挙がった。これに対し、「Box Hubs」を提案した。Box HubsはBox内のコンテンツをまとめるポータルで、広報用のHubを作成してコンテンツを追加し、そのHub自体を有効期限の自動設定対象外にすることで問題を解決した。

　だが、Hubにユーザーを直接招待すると、そのユーザーがHub内の全てのコンテンツに招待されてしまう問題が発生した。これに対しては運用ルールで対応し、ユーザーはHubに直接招待するのではなく共有リンクを作成してそのリンクからアクセスしてもらう方法を採用した。共有リンク経由なら、Hub内の各コンテンツに権限が付与されず、意図しない招待を防げる。

　また、ユーザーによる勝手なHub作成のリスクも懸念されたが、Hub作成権限を情報システム部門に限定し、広報担当者は情報システムが作成したHubに編集者として招待される仕組みを取り入れた。これにより、無断のHub作成を防ぎながらも、広報担当者は招待されたHub内で編集作業が可能となった。

図6　Box Hubsを利用した情報公開の仕組み（出典：イベント投影資料のキャプチャー）

（5）PPAPを止めさせたい（情シスからの要望）

　A社の情報システム部門が抱えるもう一つの課題は、メールにパスワード付きZIPファイルを添付し、別メールでパスワードを送る「PPAP」の運用をやめさせることだ。クラウドストレージの共有リンク送信で代替可能だが、実際にはなかなか定着しなかった。

　そこで提案されたのが、メールの添付ファイルを強制的にBoxの個人フォルダに保存し、共有リンクだけを自動でメールに記載して送信する仕組みだ。これはサードパーティー製のツールを使って実現した。

　だが、共有リンクが流出した場合のリスクが問題となり、アクセス元をワンタイムパスワードで認証する仕組みの必要性が議論されたが、Boxと連携可能なソリューションはなかった。そのため、この課題は共有リンクの運用管理、具体的には閲覧履歴の確認や不要時のリンク削除を徹底する方法で対応し、完全な解決は長期的な課題として引き続き検討されることとなった。

（6）Boxの監査をどうするか（情シスからの要望）

　PoCの終盤では、外部とのやりとりを含む監査方法が課題となった。Boxには17種類のレポート機能があり、特にオープンリンクや共有リンクの発行状況、外部コラボレーターのリストは重要だ。月次の共有リンク・ユーザーアクティビティーレポートや外部コラボレーションレポートが監査に適していることが分かった。

　だが、これらのレポートは情報システム部門で出力できても、共有の適否は組織側で判断したいため、情報システム部門だけで管理・配布するのは負担が大きい。

　そこで提案されたのが、丸紅I-DIGIOの「Log Reporter for Box」だ。膨大なレポートデータを組織ごとに自動で分割し、各組織の担当者を招待して共有リンクを通知する機能だ。これによりレポート配布と確認の負荷を大幅に軽減できる。また、レポートへのアクセス履歴も記録され、利用状況の把握も可能だ。

　こうしてPoCフェーズの課題は順次解決され、A社は無事にBoxの全社展開へと進んだ。その後のデータ移行フェーズでは「プロキシを迂回（うかい）できずBox Shuttleが使えないという問題、利用定着化フェーズでは「コラボレーターの有効期限を一括更新したい」「外部コラボレーターの招待を承認制にしたい」など、多くの課題が明らかになった。これらについても、A社と共に解決に向けて取り組んでいるところだ。

本記事はBox Japan主催の「BoxWorks Tokyo 2025」での講演内容を基に編集部で再構成した。