大規模な組織でアプリを安全に管理する 5 つのステップ

アプリは、チームがすでに作業に使用している Slack で重要なツールにアクセスできるようにすることで、チームの生産性の向上に役立ちます。管理者であるあなたの役割は、従業員に柔軟にアプリを使用させることと、オーガナイゼーション内でどのようにアプリの運用の管理を維持するかのバランスをとることです。

そのために、Slack では管理者がオーガナイゼーションの規模に応じたアプリの安全な管理をシンプルでスムーズなものにできるようにするベストプラクティスをまとめました。

アプリ管理入門

まず、アプリ管理を次の 4 つのステップに分けましょう。

1. アプリのリクエスト
2. アプリの承認と制限
3. アプリのインストール
4. アプリに対するアカウントの認証

これらのステップのそれぞれに、オーガナイゼーションのニーズに応じてアプリを調整するための、ステップ特有の決定事項があります。

各ステップを確認しながら、アプリ管理に適用するガバナンスのタイプを検討してください。決定をトップダウンで行いますか、つまり OrG 管理者とオーナーが決定してオーガナイゼーション内のすべてのワークスペースに適用しますか？

あるいは、ワークスペースの管理者が各自のワークスペースに関する決定を行う、ボトムアップの手法が適していますか？ 

オーガナイゼーションごとに意思決定の方法は異なるため、「正解」というものはありません。実際、多くのオーガナイゼーションが、トップダウンとボトムアップを組み合わせたハイブリッド方式を採用しています。 

ステップ 1 : アプリのリクエスト

オーガナイゼーションでどのアプリを使用するか、また、さらに重要なこととして、アプリがインストールされた後にどのデータを利用できるようにするかを確実に制御するには、アプリの承認を適用することが重要なステップです。 

ワークスペースに対してアプリの承認を適用する

アプリの管理設定で各ワークスペースにアプリの承認を適用できます。ワークスペースのオーナーがアプリの承認を適用し、アプリのリクエストの送信先を設定したいかどうかを選択できるという点で、これはボトムアップ手法になります。また、アプリ管理者（アプリのリクエストを審査する権限が与えられるメンバー）の役割を果たすチームメンバーを指定することもできます。

オーガナイゼーションに対してアプリの承認を適用する

OrG 管理者は、既存のすべてのワークスペースと、今後作成されるすべてのワークスペースに対して自動的にアプリの承認が適用されるようにする、オーガナイゼーションポリシーを追加できます。 

オーガナイゼーションポリシーを使用すると、アプリ管理についての決定事項がオーガナイゼーション内のすべてのワークスペースに適用されるようにすることができます。これらのポリシーは、複数のワークスペースが一様に同じルールに従うというセーフガードとして機能します。

ステップ 2 : アプリの承認と制限

アプリ管理のプロセスでアプリの承認の適用に続く次のステップは、アプリの承認と制限です。承認されるアプリと制限されるアプリに関する構造を構成し、予測ができるようにするには、基本に立ち返り、チームとして社内のセキュリティプラクティスをアプリの承認または制限の根拠とする基本理念に採り入れることが役に立ちます。 

セキュリティプラクティスとリスクの許容範囲はオーガナイゼーションごとに異なります。この情報をあらかじめ決めておくことで、オーガナイゼーションでのアプリの運用方法に関する優先順位を設定できるようになります。 

Slack 権限の評価

第一に評価できる一連の基準は、アプリが Slack ワークスペースへのアクセスに関してどのような権限をリクエストしているかということです。アプリに一定の権限を許可することのリスクとメリットを把握することが重要です。アプリはオーガナイゼーションのワークフローを変えることができますが、データ共有のコストに影響することがあります。

アプリは、Slack で次の 3 つを実行できるようにするために一定の権限をリクエストします。 

• 情報を閲覧する
• 情報を投稿する
• アクションを実行する

Jira Cloud アプリを使用した例を見てみましょう。以下は、チームによって特定されかかっているエラーについての会話です。ハリスがバグをログに記録した後に Jira Cloud アプリがチャンネルに投稿し直し、チーム全体が問題を見ることができます。 

アプリの権限は、アプリからアクセスできる API スコープとメソッドによって管理されます。Jira Cloud アプリの機能に必要な権限とスコープを詳しく見てみましょう。

• 情報を閲覧する

最初の権限セットは、情報の閲覧に関連するものです。ここで、Jira Cloud アプリは、バグを作成したのがハリスであると指定しています。このためには、Slack ユーザー ID を Jira ユーザー ID にマップできるように、「ワークスペース内のメンバーを閲覧する」権限がアプリに必要です。 

この権限を与えることで、Jira Cloud アプリはバグの作成者を簡単にすばやく確認して、Slack 内でこのユーザーにフォローアップメッセージを送信できます。Jira にこれらの詳細を検索させる必要はありません。

• 情報を投稿する

アプリがリクエストする権限の 2 つ目のタイプは、情報を投稿する権限です。Jira Cloud アプリはチャンネルに投稿を行います。これをサポートするには、アプリが Jira Cloud としてメッセージを送信するための権限が必要です。

この権限へのアクセスを与えることで、Jira Cloud アプリは、リアルタイムで通知をチャンネルに流し込みます。これによりチームはバグを確認できるようになり、問題にすばやく対処できます。

• アクションを実行する

アプリが最後にリクエストするのは、Slack 内でさまざまなアクションを実行する権限です。Jira Cloud アプリは、メンバーが通知から問題の監視や、ほかのメンバーへの割り当てなどのアクションを実行できるようにします。

この権限へのアクセスを与えることで、Jira を開き、問題を検索したり、ほかのメンバーに割り当てたりする必要がなくなり、これらのすべてを Slack 内で数回クリックするだけで実行できます。

Slack 権限の新しい詳細モデル

アプリ開発者は、アプリの機能に割り当て直す権限を要求する、詳細な権限モデルを使用します。このことにより、アプリのセキュリティフットプリントが小さくなり、アプリの承認と制限のプロセスの透明性が上がり、より具体的になるため、セキュリティ標準に合わない権限かどうかについてアプリを評価して、コンプライアンスに従ったアプリとして迅速に承認できるようになります。 

アプリのセキュリティ詳細の確認

管理者は、Slack 内の権限に加えて、アプリの開発者のセキュリティプラクティスも信頼したいと考えます。開発者は各自の App ディレクトリの新しいタブで、SOC、データ保持ポリシーの HIPAA コンプライアンス証明書などをリストして、セキュリティとコンプライアンスの詳細を明確に示すことができるようになりました。

バラバラのリソースを検索するのではなく、Slack の App ディレクトリから直接、アプリに関して重要なセキュリティとコンプライアンスの詳細を確認できます。

OrG 全体のアプリ承認の管理

次に、アプリの承認のオペレーションをスケーラブルで効率的に行うにはどうすればいいのかということが問題になります。Slack の管理機能を使用すれば、大規模なアプリの承認を簡単に管理できます。

まず、複数のワークスペース間のアプリの管理を担当する Enterprise Grid プランの管理者専用に、新しく OrG 全体のアプリの承認のためのダッシュボードが組み込まれています。 

このダッシュボードは、アプリの承認の審査プロセスを合理化するように設計され、管理者はオーガナイゼーション全体でアプリを一括して承認または制限できます。

このため、リクエストのキューの管理に必要な時間を短縮できます。さらに、ワークスペース全体について、どのアプリがリクエストされ、どれが制限され、どれが承認されたかの全体像を 1 か所で管理できるため、アプリ管理のプラクティスがオーガナイゼーション全体に適用されているかの確認にも便利です。

Slack の API を使用したアプリ承認の自動化

アプリの承認に微妙な差異を意識する管理者もいれば、アプリの承認プロセスを単に最適化したい管理者もいます。アプリ管理のための管理者用 API には、アプリ承認プロセスの一部（または全部）を自動化するカスタムアプリを作成するインフラストラクチャが用意されています。

Slack の API を使用すれば、開発者は Grid オーガナイゼーション内のすべてのワークスペースを対象にして、アプリの承認と拒否を自動化するための基準を定義し、ルールを設定することができます。

OrG のアプリ管理のためのルールのシナリオを設定すると、そのルールに応じたアクションの実行に Slack の API を利用でき、OrG 固有のニーズに沿ったカスタムソリューションを構築できます。

すべての人に社内でカスタムアプリを作成するリソースがあるわけではありません。Slack は API を使用したソリューションの作成をサポートする高度な技術企業と連携して、新しいサービスパートナープログラムを立ち上げました。開発者の雇用が必要になるなどの課題がある場合などに利用できます。 

ステップ 3 : アプリのインストール

アプリの承認に続くステップはインストールです。元のリクエストを送信したユーザーに Slackbot からメッセージが届けられ、リクエストしたワークスペースへのアプリのインストールが承認されたことが通知されます。この時点で、App ディレクトリにアクセスして、リクエスト元のワークスペースにアプリをインストールするように指示されます。

インストールのフローはアプリごとに異なります。これは各アプリでセットアップの完了までに必要になる権限と追加の設定が異なるためです。インストールフローの決定で考慮される主な要素は次の 2 つです。

• そのアプリでどのようなデータアクセスが必要になるか。アクセスが必要になるのは、Slack からのデータか、サードパーティサービスのデータか、あるいはその両方であるかといったことです。 
• アプリでどのような追加設定が必要になるか。アプリをセットアップする時に、Slack 内、サードパーティサービス内、またはその両方のうち、どこで実行する追加ステップがあるかといったことです。 

それぞれのシナリオについて、以下の例を使用してどのような状況でこれらの要素が関係するかを確認しましょう。 

データへのアクセス権の提供

データへのアクセスとなると、Slack からの権限だけあれば機能できるアプリもあります。Simple Poll というアプリは、基本的な調査のみを行い、実際に必要なものはユーザーからの回答のみです。つまり、データは Slack 内だけに存在します。 

しかし、サービスの種類にかかわりなく、連携されるサービスからのサードパーティ権限が必要なアプリもあります。例えば、Google カレンダーアプリは、ミーティングのリマインダーの送信や、ユーザーの Slack のステータスとカレンダーの同期など、基本的な機能を実行するためにユーザーのカレンダーデータへのアクセスが必要になります。

アプリの設定

権限を与えた後のステップは、追加設定の完了です。アプリのすべてで設定が必要なわけではありませんが、通常、必要とするアプリには、なんらかの形でユーザーからの手動入力が必要になります。例えば、Twitter アプリを使用している場合、つぶやきの投稿先にするチャンネルを設定する必要があります。 

通常、別のアプリマーケットプレイスの関与が必要な場合は、サードパーティサービスからの詳細設定が必要になります。例えば、Salesforce アプリをインストールする場合は、Salesforce AppExchange からアクションを実行して適切な Salesforce パッケージをインストールするために、担当の Salesforce 管理者のサポートを得る必要があります。 

アプリを承認する場合は、直接的な Slack 内での作業のみを意味するわけではないため、微妙な違いに注意することが重要です。アプリのリクエストを審査する時は、例えば、Salesforce、Workday、Zoom などのように、追加の設定が必要であるかどうかを示す付記に注意します。 

Enterprise Grid 全体にわたるアプリのデプロイ

多くの Enterprise Grid のユーザー企業にとって、特にオーガナイゼーション内で数百または数千を超えるワークスペースを管理している場合には、個々のワークスペースにアプリをインストールするのは、単にスケーラブルにできることではありません。

OrG 管理者やオーナーは、管理者ダッシュボードを使用して、複数のワークスペースにわたって一度にアプリをインストールやデプロイすることができ、アプリの配信プロセスの時間短縮と効率化を促進できます。オーガナイゼーション全体にアプリをデプロイする時、今後のワークスペースに自動的にインストールすることも設定できるため、初日から Slack で利用可能なアプリのデフォルトセットを用意できます。

Slack App ディレクトリにアクセスして、オーガナイゼーション全体にデプロイできるアプリを確認したり、Slack API のドキュメントを確認したりして、このデプロイモデルをサポートするために社内アプリをアップグレードする方法を確認してください。

ステップ 4 : アプリの認証

最後のステップとして、アプリのインストール後は、ワークスペース内のすべてのメンバーがそのアプリを検出できるようになります。しかし、インストールフローによっては、各ユーザーが個別に追加の認証ステップを実行することが必要なアプリがあります。

特に、ユーザーレベルのデータを処理するアプリでは、ユーザーそれぞれが、サードパーティサービスでの認証によって各自の個別アカウント詳細へのアプリ権限を与える必要があります。これによりユーザーは、データをアプリと自動的に共有するのではなく、カレンダーの詳細などの個人データをさらに共有するかどうかを選択できます。

チームを代表してカレンダーアプリを認証する

Slack アプリを使用するために、カレンダーアプリの追加認証ステップを完了する必要があることに気づかないユーザーもいるかもしれません。管理者は、チーム内のすべてのアカウントを認証するための一元化された方法である、ドメイン全体での認証を使用することで、Google カレンダーアプリや Outlook Calendar アプリに関してこの問題を回避することができます。ユーザーが認証されると、そのユーザーはアプリから利用開始にあたっての一連のヒントを受け取り、アプリを最大限に活用する方法を知ることができます。

このようなトップダウンのアプローチにより、オーガナイゼーション全体のユーザーが Slack からさらに大きな価値を引き出せるように支援できます。実際、1,500 人以上の従業員を抱える個人向けオンライン金融企業である SoFi では、カレンダーアプリを自動設定するドメイン認証を使い始めてから、毎週の Google カレンダー利用者数が 790% も増加しています。

Slack のセキュリティチームからのベストプラクティス

ここまでは、アプリ管理の基礎について説明しました。以下は Slack のセキュリティチームからの実用的なお役立ち情報です。

アプリの審査に関する基本理念を文書化する

自社のセキュリティチームと協力して、アプリの承認と拒否の理由に関する基本理念を決定します。明確なガイドがあれば、管理者とアプリ管理者はアプリに関してチームと連絡を取ることなく、より適切な決定を行うことができます。

オーガナイゼーションにアプリのリクエストに関する研修を行う

アプリのリクエストの品質を向上する優れた方法は、FAQ ドキュメントを作成して活用することです。メンバーがあらかじめインストールできるものとできないものを認識していればリクエストの質も向上するためです。

例えば、一部の権限を絶対に許可されないものとして制限する決定をするとしたら、なにを制限しますか？ユーザーにその理由とともに知らせることができます。

アプリを検討する時に参照を求めるガイドラインを用意することも役立ちます。最初に話を聞ける信頼できる開発者や、すでに制限されている特定のアプリについて知らせることができます。

承認済みアプリの検出の推進

脅威にさらされる対象を減らすため、Slack のセキュリティチームはアプリの反復の最小化に努めています。例えば、各サービスのユースケースが似たようなものであれば 3 種類もアンケートアプリが必要にはなりません。

特定のユースケースに最適な機能を果たすアプリを評価し、識別して、特定のアプリを使用することを従業員に推奨します（ビジネス上の理由で類似のアプリが必要な場合を除く）。

また、ユーザーは、特定のソリューションを探してアプリをリクエストするが、すでに利用できるものを認識しているわけではないという調査結果も得ています。

現在は専用の「App」ページが用意され、Slack のサイドバーから直接アクセスできます。このページではすでにワークスペースにインストールされているアプリを見つけることができます。新しいアプリをリクエストする前に、ユーザーにこのページを案内して承認済みアプリの詳細を確認できるようにします。

音声付きでもっと詳しく学習しますか？このコンテンツはウェビナー形式の「Managing apps securely and at scale」でも用意しています。