Bot Framework のセキュリティとプライバシーに関するよくある質問

各ボットは独自のサービスであり、これらのサービスの開発者には、開発者倫理規定に従ってサービス利用規約とプライバシーに関する声明を提供することが義務付けられています。 詳しくは、「Bot レビュー ガイドライン」をご覧ください。

はい。 お使いのボットはインターネット上のあらゆる場所でホストできます。 これには、ご自身のサーバー、Azure、またはその他の任意のデータ センターが含まれます。 唯一の要件は、パブリックにアクセスできる HTTPS エンドポイントがボットによって公開されている必要があることです。

ユーザーは、ディレクトリ内のボットの連絡先カードを使用して、不正な動作をするボットを報告できます。 開発者がサービスに参加するには、Microsoft サービス利用規約に従う必要があります。

お客様のボットからインターネットへの送信トラフィックをブロックしているファイアウォールがある場合は、そのファイアウォールで次の URL を許可リストに載せる必要があります。

• login.botframework.com (ボット認証)
• login.microsoftonline.com (ボット認証)
• westus.api.cognitive.microsoft.com (Luis.ai NLP 統合の場合)
• *.botframework.com (チャンネル)
• state.botframework.com (下位互換性)
• login.windows.net (Windows ログイン)
• login.windows.com (Windows ログイン)
• sts.windows.net (Windows ログイン)
• 特定の Bot Framework チャンネルのその他の URL

Bot Framework サービスは世界中の Azure データ センターでホストされているため、Azure IP の一覧は常に変わっています。 つまり、特定の IP アドレスの許可リスト登録は 1 日の間有効で、翌日に Azure IP アドレスが変わると無効になります。

Azure portal でボットを作成するには、サブスクリプションまたは特定のリソース グループのいずれかに共同作成者のアクセス権が必要です。 リソース グループの "共同作成者" ロールを持つユーザーは、その特定のリソース グループに新しいボットを作成できます。 サブスクリプションの "共同作成者" ロールのユーザーは、新規または既存のリソース グループにボットを作成できます。

Azure CLI を使用すると、ロールベースのアクセス制御の手法でカスタム ロールをサポートできます。 より制限されたアクセス許可を持つカスタム ロールを作成する場合は、次のセットを使用すると、LUIS、QnA Maker、および Application Insights もサポートするボットを作成およびデプロイできるようになります。

"Microsoft.Web/*",
"Microsoft.BotService/*",
"Microsoft.Storage/*",
"Microsoft.Resources/deployments/*",
"Microsoft.CognitiveServices/*",
"Microsoft.Search/searchServices/*",
"Microsoft.Insights/*",
"Microsoft.Insights/components/*"

1. すべての信頼できる Bot Framework 要求には、JWT トークンが付属しています。その暗号化署名は、認証ガイドに従って検証できます。 このトークンは、信頼されたサービスを攻撃者が偽装できないように設計されています。
2. お使いのボットへのすべての要求に付いているセキュリティ トークンでは ServiceUrl がエンコードされています。つまり、攻撃者がトークンにアクセスしても、会話を新しい ServiceUrl にリダイレクトすることはできません。 これは、SDK のすべての実装によって適用され、Microsoft の認証参考資料に記載されています。
3. 受信トークンが欠落しているか、形式に誤りがある場合、Bot Framework SDK の応答ではトークンが生成されません。 これにより、ボットが正しく構成されていない場合に発生する損害が制限されます。
4. ボット内で、トークンで提供される ServiceUrl を手動で確認できます。 これにより、サービス トポロジが変更された場合にボットが脆弱になります。したがって、これは可能ですが、お勧めしません。

Web チャット コントロールには、適切なユーザーがサインインしていることを保証する 2 つのメカニズムがあります。

1. マジック コード。 サインインの最後に、ランダムに生成された 6 桁のコード (マジック コード) がユーザーに表示されます。 ユーザーは、サインイン プロセスを完了するために、やり取りの際にこのコードを入力する必要があります。 これを行うと、ユーザー エクスペリエンスが悪化する傾向があります。 また、フィッシング攻撃を受けやすくなります。 悪意のあるユーザーが、別のユーザーになりすましてサインインし、フィッシング詐欺を通じてマジック コードを入手できます。

   警告

   マジック コードの使用は非推奨です。 代わりに、以下で説明する Direct Line 拡張認証の使用をお勧めします。

2. Direct Line 拡張認証 マジック コードを使用する方法で問題が発生したため、Azure AI Bot Service ではマジック コードが不要になりました。 Azure AI Bot Service では、サインイン プロセスは必ず Web チャット自体と同じブラウザー セッションでのみ完了します。 この保護を有効にするには、ボットの Web チャット クライアントをホストできる信頼された origin (信頼されたドメインとも呼ばれます) の一覧を含む Direct Line トークンを使用して、Web チャットを開始する必要があります。 強化された認証オプションを使用して、Direct Line 構成ページで信頼された origin の一覧を静的に指定できます。 詳細については、「Direct Line 拡張認証」を参照してください。

ID およびアクセス管理 (IAM) は、適切なユーザーがテクノロジ リソースに適切にアクセスできるようにするためのフレームワーク (ポリシーとテクノロジ) です。 詳細については、ID 管理を参照してください。

Bot Framework には、次の識別メカニズムが用意されています。

• ボット認証。 要求が正当なソースから送信されたかどうかを判断します。 ボット コネクタ サービスによって制御され、ボットとチャネル間での安全な通信が可能になります。 詳細については、ボット認証に関するページをご覧ください。

• ユーザー認証。 これにより、ボットがユーザーに代わってセキュリティで保護されたオンライン リソースにアクセスできるようになります。 業界標準の OAuth は、ユーザーを認証し、ボットがリソースにアクセスすることを承認するために使用されます。 詳細については、「ユーザー認証」を参照してください。

要約すると、Bot Framework はサービス間認証 (ボット認証) を処理し、基本的には要求が実際に適切なチャネルから送信されたことを検証します。 ボットは、より低いレベルの認証を処理する役割を担います。 フィルターを適用して、ボットが特定のテナント ID からの要求のみを受け入れるようにするか、ユーザーに一部の OAuth サービス (ユーザー認証) による認証を要求することができます。

ボットが処理する受信メッセージを制限するには、2 つの異なるオプションがあります。

• セキュリティで保護されたデータを扱う場合は、OAuth を使用してユーザーを認証することをお勧めします。

• ミドルウェアの使用は、もう 1 つの優れた選択肢です。 たとえば、Teams チャネルでは、Teams チャネル データからテナント ID を取得するミドルウェアを作成できます。 その後、ミドルウェアは、受信アクティビティをボット ロジックに継続させるか、代わりにエラー メッセージを返すかを決定できます。

  警告

  Teams がさまざまなテナントからメッセージを送信するのを防ぐことも、アプリ マニフェストを持つ誰かがボットをインストールするのを防ぐこともできません。 実行できる操作は、ボットが望ましくないメッセージを処理できないようにすることだけです。