SlackとMicrosoft Teamsを統合する際の考慮事項とベストプラクティス
Access RequestsをSlackやMicrosoft Teamsと統合することで、リクエスト管理を合理化し、ユーザーの生産性を向上させることができます。
orgでIdentity Governance - Slack通知機能を有効にした場合は、Slackを使用してアクセス認定キャンペーンのレビュアーと管理者に通知することもできます。
ただし、SlackやMicrosoft TeamsをOkta orgと統合する前に、次の考慮事項とベストプラクティスに留意してください。
考慮事項
-
SlackとMicrosoft Teamsでのリクエストと承認は、Oktaセッションではなくチャットアプリセッションを使用します。チャットアプリは認証ポリシーが緩和されることが多いため、アクションの保証レベルがorgのセキュリティ標準を満たさない場合があります。チャットセッションが侵害された場合、不正者がOktaで再認証せずにリクエストを行える可能性があります。
-
この統合は、メールアドレスによってチャットアプリユーザーをOktaユーザーと照合します。これらの属性が厳格に管理されていない場合（つまり、ユーザーが編集できる場合や信頼できるシステムからソーシングされていない場合）、ユーザーが他のユーザーに成りすまして不正アクセスを行う可能性があります。
-
ユーザーは、個別に割り当てられた承認者でない限り、自分自身のリクエストを承認できません。これにより、侵害されたIDが、自分自身のアクセスリクエストの送信と承認やセルフエスカレーションに使用されるのを防ぐことができます。
-
Okta管理者ロールのリクエストをチャットアプリから送信・承認することはできません。要求者はOkta End-User Dashboardから管理者ロールアクセスをリクエストする必要があり、承認者はOkta Access Requestsアプリで管理者ロールアクセスを承認する必要があります。このアプローチによって、両方のアクションには有効なOktaセッションが必須となり、機密性の高いアクションには最も強力な認証ポリシーが適用されます。
ベストプラクティス
-
強力な認証およびセッションポリシーを適用する
SlackとMicrosoft TeamsでのAccess Requestsのセキュリティは、チャットアプリのセキュリティに左右されます。頻繁な再認証を強制するようにSlackとTeamsのアプリ認証ポリシーを構成してください。これにより、侵害されたセッションが長時間有効になるリスクを軽減できます。重要なアプリには、頻繁な再認証と、フィッシング耐性のあるMFAなどの強力な要素を必須にしてください。そうすれば、不正なアクセスがAccess Requestsを通じて承認された場合でも、ユーザーは高い保証レベルを満たさなければそのアクセスを使用できません。
-
Universal Logoutを有効にする
リスクが検出されると、Universal Logoutはセッションを直ちに終了します。現在Slack Enterpriseでサポートされており、リスク検出時にセッションの終了を呼び出すように構成できます。対応アプリの一覧については、「Universal Logoutに対応するサードパーティアプリ」を参照してください。
-
データソースを一元化する
人事情報システム（HRIS）やActive Directoryなど、単一の信頼できるソースからメールアドレスなどの重要なユーザー属性を同期します。ユーザーが自分のメールアドレスを編集できないようにチャットアプリの設定を構成します。これにより、攻撃者が他のユーザーに成りすまして承認ワークフローをバイパスすることができなくなります。
-
統一された要求者エクスペリエンス機能を有効にする
統一された要求者エクスペリエンス機能を有効にすると、すべてのユーザーがリクエスト送信のためにWebにリダイレクトされるため、有効なOktaセッションが必要になります。承認は引き続きSlack内で行われますが、これにより不正アクセスのリスクの高いベクトルが排除されます。統一された要求者エクスペリエンスによって、アクセスを取得するためには必ずOktaセッションが必要になるため、セキュリティポスチャを強化できます。