はじめに

社内情報システム部兼 CISO室コーポレートエンジニア id:rotom です。一休のコーポレートIT・セキュリティ領域はだいたい全部見てます。

このエントリは 一休.com Advent Calendar 2023 11日目の記事です。昨日は id:naoya による TypeScriptでどこまで「関数型プログラミング」するか ─ 「手続き Haskell」から考察するでした。その他の素敵なエントリも以下のリンクからご覧ください。

qiita.com

一休は今年、全社利用しているコミュニケーションツールである Slack を Enterprise Grid へ移行しました。 Enterprise Grid はその名の通り大規模なエンタープライズ組織向けの管理機能・セキュリティ機能が拡充されたもので、他のプランとは大きく思想が異なります。

Enterprise Grid について取り上げたエントリは多くありますが、その中でも「情報バリア」について詳しく書かれた記事が無かったので、本エントリで解説します。

Enterprise Grid に関する詳細な説明はここでは割愛するので、公式ドキュメントをご覧いただくか、Slack サポートにお問い合わせください。

slack.com

Enterprise Grid 移行と課題

一休ではエンジニアに限らず全ての従業員が Slack をコミュニケーションツールとして利用しています。これまではビジネスプラスプランで利用してきましたが、監査ログや DLP などの機能を利用し、よりセキュリティ・コンプライアンス体制を強化するため、Enterprise Grid へ移行することにしました。

一休には従前、日常的に利用している一般のワークスペースと、機密情報を取り扱うワークスペースの2つのワークスペースが存在しました。これらのワークスペースは完全に独立しており、機密情報は一般のワークスペースに持ち出すことができないよう厳しく統制されていました。

今回 Enterprise Grid に移行するにあたり、マルチワークスペースに対応することから、この2つのワークスペースは1つの OrG 配下に置くことにしました。

この際、仕様として OrG 配下のユーザーは、自分が所属していないワークスペースのユーザーに対してもダイレクトメッセージやハドルミーティングが可能です。ワークスペース間でのダイレクトメッセージやハドルミーティングを禁止する設定は行えず、情報の持ち出しを防ぐために対策が必要でした。

情報バリアとは

この問題を解決するために、Enterprise Grid の情報バリアという機能を利用しました。

Slack 管理者でもビジネスプラス以下のプランの方は聞いたことがない人も多いと思います。あるいは、既に Enterprise Grid で運用している組織でも利用していないことが多いかもしれません。

slack.com

簡単にまとめると、特定の IDPグループ間でのダイレクトメッセージやハドルミーティングを禁止することができる機能です。

また IDPグループという聞き慣れない用語が現れましたが、これは Okta や Microsoft Entra ID などの IdP（Identity Provider）のグループを Slack 上に連携させ、チャンネルやワークスペースと紐付けることができる Enterprise Grid の機能です。

slack.com

この機能を利用することで、擬似的にワークスペース間のダイレクトメッセージ・ハドルミーティングを禁止にすることができると考えました。

情報バリアの設計

ここからは実際に情報バリアの構築した手順を解説します。これから情報バリアの利用を開始しようとしている方は業務影響のない Sandbox 環境で検証してから設定することを推奨します。

IDPグループの作成

IdP として利用している Microsoft Entra ID 側に一般ワークスペース、機密情報ワークスペースそれぞれに所属するユーザーを追加したグループを用意します。このグループは SCIM（System for Cross-domain Identity Management）により、対応する IDPグループを OrG 上に作成され、Microsoft Entra ID 側のグループに追加されたユーザーの Slack アカウントが自動的に追加されるようになります。

IDPグループは複数のワークスペースやチャンネルと接続することが可能ですが、今回の用途ではそれぞれのグループに対応するワークスペース1つずつに接続します。これにより Microsoft Entra ID 側で対象のグループに追加されたメンバーは、自動的にワークスペースへ追加されます。

なお、IDPグループの名称変更やユーザーの追加・移動・削除は Slack OrG 管理画面の GUI 上は行えません。全て SCIM で連携されているので IdP 側で変更し、プロビジョニングする必要があります。 API による操作は可能なので必要に応じて SCIM API を利用して操作することは可能です。

情報バリアの有効化

情報バリアは標準で利用できないオプトイン機能なので、OrG オーナーより Slack サポートチームに連絡をして有効化する必要があります。 OrG 管理者やワークスペースのオーナーでもリクエストができないので、ご自身が OrG オーナーではない場合は OrG オーナーにリクエストを依頼してください。

リクエストは /feadback で「 {yourdomain}.enterprise.slack.com で情報バリアが利用できるように機能を有効化してください。」のよう送信すれば OK です。

機能が有効化されると OrG 管理コンソール > セキュリティ > 情報バリアの項目が開けるようになります。

情報バリアの設定

情報バリア内から「障壁を作成」ボタンを押すと情報バリアを作成することができます。なぜかここではバリアが障壁と訳されていますが、気にしないでください。

ここではプライマリーグループにIDPグループ（一般）、障壁の対象にIDPグループ（機密情報）を入力しました。対象は複数の IDP グループを指定することが可能です。

実現

ここまで設定が完了すると、IDPグループ間で情報バリアが作成されます。

別のワークスペースに所属するユーザーのダイレクトメッセージ画面を開くと、このようにポリシーによって送信ができない旨メッセージが表示され、送信ができなくなります。情報バリアの設定は OrG 画面から設定後、即時反映されるわけではなく少しラグがありました。設定後は少し時間をおいてから動作確認を行うことをおすすめします。

これにより、IdP グループ間の情報バリアの設定で実質的にワークスペース間のダイレクトメッセージ・ハドルミーティングを禁止することができました。

終わりに

Enterprise Grid への移行時に発生した課題と、情報バリアを使って解決した話を書きました。要所のみ掻い摘んで記載しましたが、Enterprise Grid への移行は他の SaaS のシンプルなプランアップグレードではなく、イニシャルコストとダウンタイムを伴いながら環境を丸ごとお引越しすることになるため、本件以外にも想定外の様々な課題があり、Slack（Salesforce）マネージャー / アーキテクトにサポートいただきながらプロジェクトを完遂できました。

個人的にはSlack 認定管理者試験で学んだ Enterprise Grid の知識を実践で活用することができ、今年最も成長できたプロジェクトのひとつだったと思っています。

私も Enterprise Grid 管理者 1年生なので内容に誤りや、もっと良い方法があるよ！といったご指摘 / ご助言があれば X や情シス Slack などでご連絡いただけると嬉しいです。