Amazon Connectのアラートから考える複数アラート検知による危険性 - Prisma^® Cloudから考えるセキュリティ（5）

クラウドサービス部の新山です。

ラックでは、Prisma^® Cloud（プリズマクラウド）を用いたクラウドセキュリティ統制支援サービスを提供しています。Prisma^® Cloudは、パロアルトネットワークス社が展開する、マルチクラウドやハイブリッドクラウド環境におけるクラウドリソースの設定上の脆弱性や不審な挙動を、業界標準の各種コンプライアンス基準や独自の基準に従い、継続的に監視・可視化するSaaS型のサービスです。

機能の1つとして、Prisma^® Cloud側で事前定義されたアラートポリシーに基づいて不適切な設定や不審な挙動を検知・アラートします。非常に多くのアラートポリシーが定義されているので、そのなかでも特に注意したいものを連載でお届けします。

連載5回目となる本記事では、2025年1月の更新情報で追加された「AWS Connect instance not configured with contact flow logs」というアラートポリシーを参考に、他のポリシーと併せて検出された場合の注意点について紹介します。

アラートの内容

このアラートは、Amazon Connectインスタンスにおいてコンタクトフローログ（問い合わせフローのフローログ）が有効になっていない状態を検知するものです。Amazon Connectとは、企業が顧客との通話やチャットを簡単に管理・自動化できるようにするためのAIを活用したアプリケーションです。

コンタクトフローログは、顧客とのやりとりがどのように処理されたか^※を記録する重要なログです。

※ 自動音声応答（IVR）の経路、オペレーターへの転送など

これが有効になっていないことによるリスクは、不審なアクセスや設定ミスによる情報漏えい、なりすまし、通話経路の改ざんなどが発生しても、その痕跡をたどることができず、影響範囲の特定や原因の追跡が困難になるという点です。特に、顧客との通話内容や問い合わせ対応の流れが不正に操作された場合、通話内容や顧客情報が改ざんされる危険性が高まり、内部不正や外部からの攻撃に気づけず、被害が広がる恐れがあります。

そのため、コンタクトフローログはセキュリティ監査やトラブル対応の観点からも必ず有効化しておくべき基本設定であり、このアラートが検知された場合は、早急にログ記録の設定を確認・修正することが強く推奨されます。

対処方法

対処方法はコンタクトフローログを有効にすることです。デフォルトでコンタクトフローログは有効になっていますが、無効になっている場合は、Amazon Connectの「問い合わせフロー」をクリックして設定項目の「フローログを有効にする」にチェックを入れ保存することで、コンタクトフローログを有効にできます。

リスクを高める関連ポリシー

今回紹介したポリシー単体では、内部不正やシステムの悪用が発生した際に影響範囲の特定や原因の追跡が困難になるという課題はあるものの、不審なアクセスや情報漏えいといった直接的なリスクは一見小さく感じられるかもしれません。しかし、このポリシーが他の特定のポリシーと併せて検出された場合、リスクが一気に深刻化する可能性があります。

ここでは、特に注意が必要な併発ポリシーと、それによって生じ得るリスクについて紹介します。

AWS Connect instance using publicly accessible S3 bucket

このポリシーも、今回紹介した「AWS Connect instance not configured with contact flow logs」と同様に、2025年1月に追加された新しいポリシーです。このポリシーは、Amazon Connectインスタンスが録音データやチャット履歴などを保存するS3バケットが、インターネットからアクセス可能な状態になっているかどうかを検知するものです。

例えば、S3バケットのアクセス制御（ACL）やバケットポリシーの設定に問題があり、AllUsersやAuthenticatedUsersに読み取り権限が付与されていたり、パブリックアクセスのブロック設定が無効になっていたりすると、このポリシーにより検出されます。このポリシーと「AWS Connect instance not configured with contact flow logs」を併せて検出している場合、ユーザー対応内容（録音、チャットログ、画面キャプチャなど）の外部流出の危険性が高まるだけでなく、コンタクトフローログが無効なため、どの経路で誰が何を行ったかを追跡できないという深刻なリスクが考えられます。

既にインターネット上にはパブリック公開されていたAWS S3バケットおよびその中のファイルを検索・閲覧できるサイトも存在しており、公開後数分で対象ストレージがインデックス化されてしまうといった危険性も指摘されています。つまり、誤って外部に公開してしまったS3バケットへの対処は可能な限り早急に行う必要があるということです。

パブリックアクセスを無効にする方法はいくつか考えられますが、Amazon Connectが保存先として使用しているS3バケットに対して、S3バケットのパブリックアクセスをブロックすることが最も確実で、まず初めに実施すべき対処となります。対象のバケットの「アクセス許可」タブから「ブロックパブリックアクセス（バケット設定）」の編集をクリックし、「パブリックアクセスをすべてブロック」にチェックを入れ「変更の保存」をすることで、パブリックアクセスを無効にできます。

デフォルト設定では「パブリックアクセスをすべてブロック」にチェックが入っていますので、パブリックアクセスがブロックされている場合は意図した設定となります。パブリックアクセスがブロックされていても、最小権限の原則を徹底することは重要なので、以下の対応を実施することでセキュリティを強化し、データの安全性を確保することができます。

• バケットポリシー、ACLの見直し
• IAMポリシーでのアクセス制御
• ログ設定の強化

特に最後に挙げたログ設定の強化については、S3のアクセスログやCloudTrailの設定をすることはセキュリティ調査時に不可欠であり、トラブル時の原因特定や対応の迅速化につながります。CloudTrailを有効にしておくことで、Amazon Connectの構成変更やS3関連のAPIコールも追跡できるようになります。Prisma^® Cloudでは、もちろんS3のアクセスログやCloudTrailの設定に関するポリシーも準備されていますので、以下アラートポリシーも併せて検知することにより、リスクが高まっているか確認できます。

• AWS Access logging not enabled on S3 buckets
  S3のアクセスログの無効を検知するポリシー
• AWS CloudTrail is not enabled on the account
  アカウントでCloudTrailが無効になっていることを検知するポリシー

おわりに

今回は2025年1月に追加されたポリシーをもとに、Amazon Connectに焦点を当てましたが、同様のリスクは他のAWSサービスでも発生し得ます。フローログの有効化や、S3バケットなどのパブリックアクセスの無効化は、全体的なセキュリティレベルを高めるうえで基本かつ重要な対策です。これを機に、環境全体を見直すきっかけとしていただければと思います。

また、今回紹介したアラート以外にも、Prisma^® Cloudでは多数のセキュリティリスクを検知します。そして、ラックの長年にわたるシステム開発とセキュリティのノウハウを集め提供する「クラウドセキュリティ統制支援サービス」では、検知したアラートの対応を支援するサービスも提供しています。

AWS含め、パブリッククラウドのセキュリティに不安がありましたら、ぜひラックにご相談ください。