Bot Framework のセキュリティ ガイドラインBot Framework security guidelines

適用対象: SDK v4APPLIES TO: SDK v4

ボットは、金融サービス、小売、旅行などの主要なビジネス分野でますます普及しています。Bots are more and more prevalent in key business areas like financial services, retail, travel, and so on. ボットは、クレジット カード、SSN、銀行口座、その他の個人情報などの非常に機密性の高いデータを収集する場合があります。A bot might collect very sensitive data such as credit cards, SSN, bank accounts, and other personal information. そのため、ボットはセキュリティで保護され、一般的な脅威や脆弱性から保護することが重要です。So, it is important that bots are secure and protect against common threats and vulnerabilities.

ボットのセキュリティを向上させるために、いくつかの標準的な予防措置を講じすることができます。You can take some standard preventative measures to improve your bot's security. 一部のセキュリティ対策は、他のソフトウェア システムで使用されるセキュリティ対策に似ていますが、一部のセキュリティ対策はBot Framework。Some security measures are similar to the ones used in other software systems, while some are specific to the Bot Framework. 後者については、「Azure セキュリティ ベンチマーク」 を参照してくださいFor the latter, refer to the Azure Security Benchmark. このベンチマークでは、Azure でクラウド ソリューションをセキュリティで保護する方法に関する推奨事項が提供されます。The benchmark provides recommendations on how you can secure your cloud solutions on Azure.

一言で言えば、セキュリティの問題Security issues in a nutshell

この記事では、セキュリティの問題を 2 つのカテゴリにグループ化します。This article groups security issues into 2 categories:

  • 脅威: なりすまし、改ざん、情報の開示、サービス拒否など、ボットを侵害するために誰かが使用する可能性がある戦術。Threats: The tactics someone might use to compromise your bot, such as spoofing, tampering, disclosing information, denial of service, and so on.

  • 脆弱性: ボットまたはボットの管理が、バグやセキュリティの低さなどの戦術の影響を受けやすい可能性がある方法。Vulnerabilities: The ways in which your bot or the management of your bot might be susceptible to such tactics, such as bugs, or lax security.

脆弱性を減らすことは脅威を軽減するための適切な方法であり、脆弱性を軽減する既知の方法は、開発およびデプロイ プロセスでセキュリティ チェック ポイントを実装する方法です。Reducing your vulnerabilities is a good way to mitigate threats, and a known way to reduce vulnerabilities is to implement security check points in the development and deployment process.

一般的なセキュリティ ガイドラインCommon security guidelines

次の領域は、すべてのアプリケーションに共通する標準的なセキュリティのベスト プラクティスの一部でカバーされています。The following areas are covered by some standard security best practices common to all applications.

プロトコルと暗号化Protocols and Encryption

データは送信中に改ざんされる可能性があります。Data can be tampered with during transmission. 誤用や改ざんの問題に対処する暗号化を提供するプロトコルが存在します。Protocols exist that provide encryption to address problems of misuse and tampering. この点で、ボットの通信は暗号化されたチャネルを介してのみ行う必要があります。In this regard, bots should communicate only over encrypted channels. これにより、受信者と送信者以外のユーザーがメッセージまたはトランザクションの一部を見るのを難しくします。This makes it hard for anyone other than the receiver and sender from seeing any part of the message or transaction.

暗号化は、ボットのセキュリティを確保するための最も堅牢な方法の 1 つであり、企業は機密データを対人化および暗号化するための対策を講じ、その有効性を事前に保証する必要があります。Encryption is one of the most robust methods of ensuring bot security and companies must proactively guarantee its effectiveness by taking measures to depersonalize and encrypt sensitive data.

ネットワーク上のデータを交換するには、セキュリティで保護されたシステムで HTTPS プロトコルを使用する必要があります。このプロトコルは、トランスポート層セキュリティ (TLS) または Secure Sockets Layer (SSL) によって保護された暗号化された接続で HTTP 経由でデータ 転送します。To exchange data on the wire any secure system must use the HTTPS protocol, which transfers data over HTTP in encrypted connections protected by Transport Layer Security (TLS) or Secure Sockets Layer (SSL). 「RFC 2818 - HTTP Over TLS 」も参照してくださいSee also RFC 2818 - HTTP Over TLS.

自己破棄メッセージSelf-destructing messages

機密データが不要になったらすぐに削除します。通常は、メッセージ交換が終了した後、または一定の時間が経過した後に、そのデータを完全に削除します。Permanently delete any sensitive data as soon as it is no longer needed, usually after the message exchange ends, or after a certain amount of time. これには、個人を識別する情報、Id、Pin、パスワード、セキュリティの質問と回答などが含まれます。This can include personally-identifying information, IDs, PINs, passwords, security questions and answers, and so so.

データ ストレージData storage

ベストプラクティスは、情報を一定の時間、セキュリティで保護された状態に格納してから、その目的を実現した後で破棄することをお勧めします。The best practice calls for storing information in a secure state for a certain amount of time and then discarding it later after it served its purpose.

いくつかの一般的なセキュリティ手法を以下に示します。Some common security techniques are listed below.

データベースファイアウォールDatabase firewalls

  • ファイアウォールは、トラフィックへのアクセスを既定で拒否します。Firewalls deny access to traffic by default. 許可されるトラフィックは、データにアクセスする必要がある特定のアプリケーションまたは web サーバーだけです。The only traffic allowed should originate from specific applications or web servers that need to access the data.
  • また、web アプリケーションファイアウォールもデプロイする必要があります。You should also deploy a web application firewall. これは、web アプリケーションに送られる SQL インジェクション攻撃などの攻撃を使用して、データベースのデータを抜き取るまたは削除できるためです。This is because attacks such as SQL injection attacks directed at a web application can be used to exfiltrate or delete data from the database.

データベースのセキュリティ強化Database hardening

  • データベースがベンダーによって引き続きサポートされていること、およびすべてのセキュリティパッチがインストールされている最新バージョンのデータベースを実行していることを確認して、既知の脆弱性を削除します。Make sure that the database is still supported by the vendor, and you are running the latest version of the database with all the security patches installed to remove known vulnerabilities.
  • 不要なすべての機能またはサービスをアンインストールまたは無効にし、既定のアカウントのパスワードを既定値から変更するようにします。または、不要な既定のアカウントを削除します。Uninstall or disable any features or services that you don't need and make sure you change the passwords of any default accounts from their default values; or better, delete any default accounts that you don't need.
  • データベースによって提供されるすべてのデータベースセキュリティコントロールが有効になっていることを確認します。ただし、特定の理由が無効になっている場合を除きます。Make sure that all the database security controls provided by the database are enabled, unless there is a specific reason for any to be disabled.

重要な情報を最小限に抑えるMinimize valuable information

  • データベースに存在する必要がない機密情報を格納していないことを確認します。Make sure that you are not storing any confidential information that doesn't need to be in the database.
  • コンプライアンスまたはその他の目的で保持されているデータは、より安全なストレージに移動できます。オフラインでは、データベースのセキュリティの脅威を受ける可能性が低くなります。Data retained for compliance or other purposes can be moved to more secure storage, perhaps offline, which is less susceptible to database security threats.
  • 元のインストール手順でサーバーによって書き込まれた履歴ファイルを必ず削除してください。Make sure to delete any history files that are written by a server during the original installation procedure. インストールが成功した場合、これらのファイルには値はありませんが、悪用される可能性がある情報を含めることができます。If the installation is successful these files have no value but can contain information that can potentially be exploited.

EducationEducation

ボットは、会社とその顧客間の革新的な対話ツールを提供します。Bots provide an innovative interaction tool between a company and its customers. しかし、会社の Web サイトを改ざんするバックドアを提供する可能性があります。But they could potentially provide a backdoor for tampering with a company's website. そのため、会社は、開発者が Web サイトのセキュリティの一部としてボット セキュリティの重要性を理解する必要があります。Therefore, a company must assure that its developers understand the importance of bot security as part of the website security. さらに、ユーザーのエラーも問題になる可能性があります。Moreover, users' errors can be a problem, too. これには、ボットを安全に使用する方法に関する教育が必要です。次に例を示します。This will require some education on how bots can be used securely, for example:

  • 開発者の場合、ボットを安全に使用する方法に関する内部トレーニングを戦略に含める必要があります。For the developers, a strategy should include internal training on how to use the bot securely.
  • お客様には、ボットを安全に操作する方法を詳しく説明するガイドラインを提供できます。Customers can be given guidelines detailing how to interact with the bot safely.

ボット固有のセキュリティ ガイドラインBot-specific security guidelines

次の領域は、アプリケーションのセキュリティに関する標準的なベスト プラクティスBot Frameworkされています。The following areas are covered by some standard security best practices for Bot Framework applications. 次のガイドラインでは、ベスト プラクティスBot Frameworkのベスト プラクティスについて説明します。The following guidelines describe the Bot Framework best practice security measures. 詳細については、「セキュリティとプライバシーに関 する FAQ」を参照してくださいFor more information, see the Security and Privacy FAQ.

Bot Connector 認証Bot Connector authentication

Bot Connector サービスは、ボットとチャネル (ユーザー) 間でメッセージを交換するために HTTPS をネイティブに使用します。The Bot Connector service natively uses HTTPS to exchange messages between a bot and channels (users). Bot Framework SDK では、基本的なボットからチャネルへの認証が自動化されます。the Bot Framework SDK automates basic bot-to-channel authentication for you.

警告

独自の認証コードを記述する場合は、すべてのセキュリティ プロシージャを正しく実装することが不可欠です。If you are writing your own authentication code, it is critical that you implement all security procedures correctly. 認証に関する記事で説明されているすべての手順を実装することで、攻撃者がボットに送信されたメッセージを読み取り、ボットを偽装するメッセージを送信し、秘密鍵を盗むリスクを軽減できます。By implementing all steps described in the Authentication article, you can mitigate the risk of an attacker being able to read messages that are sent to your bot, send messages that impersonate your bot, and steal secret keys.

ユーザー認証User authentication

Azure Bot Service 認証 を使用すると、各種 ID プロバイダー (Azure Active DirectoryGitHubUber など) に対してユーザーを認証し、これらから アクセス トークン を取得できます。Azure Bot Service authentication enables you to authenticate users to and get access tokens from a variety of identity providers such as Azure Active Directory, GitHub, Uber and so on. カスタム OAuth2 ID プロバイダーの認証も構成できます。You can also configure authentication for a custom OAuth2 identity provider. これだけで、サポートされているすべての ID プロバイダーとチャネルで動作する 1 つの認証コード を作成できます。All this enables you to write one piece of authentication code that works across all supported identity providers and channels. これらの機能を利用するには、次の手順を実行する必要があります。To utilize these capabilities you need to perform the following steps:

  1. ボットで、ID プロバイダーでのアプリケーション登録の詳細を含む settings を静的に構成します。Statically configure settings on your bot that contains the details of your application registration with an identity provider.
  2. 前の手順で指定したアプリケーション情報に基づき、OAuthCard を使用して、ユーザーをサインインします。Use an OAuthCard, backed by the application information you supplied in the previous step, to sign-in a user.
  3. Azure Bot Service API を使用してアクセス トークンを取得します。Retrieve access tokens through Azure Bot Service API. 認証されたユーザーが ログインを続け続けできる期間に制限を設定するのをお 使いくださいA good practice is to place a time limit on how long an authenticated user can stay logged in.

詳細については、ユーザー認証に関する 記事を参照 してください。For more information, see the User authentication article.

Web チャットWeb Chat

このコントロール を使用Web チャット 偽装と ID スプーフィングに関する重要なセキュリティに関する考慮事項に注意する必要があります。When you use the Web Chat control you must keep in mind some important security considerations about impersonation and identity spoofing. 詳細については、「拡張認証のDirect Line を参照してくださいFor more information, see Direct Line enhanced authentication.

関連情報Additional information