アプリ管理の管理者ガイド

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

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

アプリ管理入門

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 権限の新しい詳細モデル

この Jira の例から、アプリが機能するには一定の権限が不可欠であることがわかったと思います。しかし、アプリがときどき広範な権限セットをリクエストすることがあります。それらの権限がいつでも明らかにアプリの機能に割り当てられるわけではありません。それどころか、アプリが不必要な量のデータをリクエストしているような場合もあります。 

この気がかりな問題に対処するため、Slack は新たに詳細な権限モデルを導入しました。アプリの開発者はこれによりアプリの機能に必要なスコープのみをリクエストできるようになります。

アプリ開発者が詳細な権限モデルの採用を進めると、アプリの機能に割り当て直すことがリクエストされる権限セットが次第に絞り込まれ、セキュリティフットプリント全体が小さくなります。

管理者やアプリマネージャーから見ると、アプリの承認と制限のプロセスの透明性が上がり、より具体的になるため、セキュリティ標準に合わない権限かどうかについてアプリを評価して、コンプライアンスに従ったアプリとして迅速に承認できるようになります。 

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

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

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

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

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

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

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

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

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

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

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

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

[aside headline="カスタムアプリを作成するロジックの例" description="" bullets="アプリのリクエストが提出されると、リクエストが JIRA などのサードパーティのチケット管理システムに転送され、レビューが行われる|<br />少なくとも 1 つ以上のワークプレイスでアプリがすでに承認されている場合は、それ以降、どのワークスペースからリクエストされた場合でもそのアプリは承認される|<br />アプリが固有のスコープを使用している場合、そのアプリは承認または制限される|<br />アプリが特定のワークスペースでリクエストされている場合はそのアプリを承認または制限される /]

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

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

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

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

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

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

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

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

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

アプリの設定

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

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

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

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

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

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

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

ここまでで、アプリ管理の基盤ができています。以下は Slack のセキュリティチームからの実用的なお役立ち情報です。

アプリのレビューに関する基本理念を文書化する

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

[aside headline="基本理念について考えるときのヒントをいくつか紹介します。" description="" bullets="アプリでどのような種類の Slack データが処理されるか|アクセスしようとしているコンテンツの機密性はどのようであるか|誰がアプリを使用することになるのか /]

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

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

たとえば、一部の権限を絶対に許可されないものとして制限する決定をすると、どうなるでしょうか?ユーザーにその理由とともに知らせることができます。アプリを検討する時に参照を求めるガイドラインを用意することも役立ちます。最初に接触できる信頼性できる開発者や、すでに制限されている特定のアプリについて知らせることができます。

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

脅威にさらされる対象を減らすため、Slack のセキュリティチームはアプリの反復の最小化に努めています。たとえば、各サービスのユースケースが似たようなものであれば 3 種類もアンケートアプリが必要にはなりません。特定のユースケースに最適な機能を果たすアプリを評価し、識別して、ビジネス上の理由で類似のアプリが必要な場合を除き、特定のアプリを使用することを従業員に推奨します。

また、ユーザーは、特定のソリューションを探してアプリをリクエストし、すでに利用できるものを認識しているわけではないという調査結果も得ています。現在は専用の「App」ページを用意し、Slack の右サイドバーからアクセスできます。このページではすでにワークスペースにインストールされているアプリを見つけることができます。

新しいアプリをリクエストする前に、ユーザーをこのページに案内して承認済みアプリの詳細を確認できるようにします。

音声付きでもっと詳しく学習しますか?このコンテンツはウェビナー形式の「大きなスケールでアプリを安全に管理する」でも用意しています。

この情報はお役に立ちましたか?

0/600

助かります!

ご意見ありがとうございました!

了解です!

ご意見ありがとうございました!

うーん、システムがなにか不具合を起こしてるみたいです。後でもう一度お試しください。