re:Invent 2024: AWSでのコンプライアンス自動化 - Audit ManagerとConfigの活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How to maintain and automate compliance on AWS (SEC319)
この動画では、AWSにおけるコンプライアンスの維持と自動化について解説しています。AWS Audit Managerを使用したコンプライアンス情報の自動収集、AWS ConfigとAWS Security Hubによるセキュリティとコンプライアンスのチェック作成、そしてAWS Systems Managerを用いた自動修復の方法を具体的に説明しています。特にPCI DSSフレームワークを例に、AWS Configでの自動コンプライアンスチェックの作成方法や、Security Hubを使用した脆弱性評価の実践的なデモを交えながら、複数のアカウントやリージョンにまたがる大規模な環境でのコンプライアンス維持の方法を詳しく解説しています。AWS Artifactを活用したコンプライアンスレポートの管理や、Conformance Packsを用いた効率的なルール展開など、実務で即活用できる具体的な手法も紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSにおけるコンプライアンス自動化の重要性
みなさん、こんにちは。AWSにおけるコンプライアンスの維持と自動化についてのセッションへようこそ。私はCristina Rios Iribarrenで、パブリックセクターのお客様向けのSolutions Architect Team Leadを務めています。そして私はLaura Verghoteで、AWSのパブリックセクター向けSenior Solutions Architectです。本日は、AWS上のリソースでいかにしてスケールを伴うコンプライアンスを維持するかについて学んでいただきます。まずは、コンプライアンスがなぜそれほど重要なのかという背景から始めていきましょう。
お客様が大規模な監査を実施する際によく直面する課題と、AWSがどのようにお手伝いできるかについてお話しします。 AWS Audit Managerを使用してコンプライアンス情報の収集を自動化する方法について学んでいただきます。そして、データソースの確認、AWS Configを使用した自動コンプライアンスチェックの作成方法、AWS Security Hubを使用した脆弱性評価の方法について見ていきます。 さらに、AWS Systems Managerを使用してこれらのセキュリティとコンプライアンスのリスクに対する是正措置を講じる方法もご紹介します。
まず共通認識として、ここでいうコンプライアンスとは、クラウドに関連する規制要件を指します。なぜこれが重要なのでしょうか？法令を遵守し、リスクを管理し、お客様からの信頼を維持することが重要だからです。セキュリティ侵害や規制上の問題が発生すると、お客様の信頼を簡単に失ってしまう可能性があり、私たちはそれを防ぐお手伝いをしたいと考えています。では、なぜ自動化なのでしょうか？答えは非常にシンプルです：人間はミスを起こしやすいからです。 コンプライアンスを自動化することで、異なるリージョンやアカウント、そしてすべての環境で一貫性を確保できます。 インフラストラクチャをより迅速にプロビジョニングでき、その時間を本来のビジネス目標に振り向けることができます。 再利用可能なテンプレートを作成し、それを異なるプロジェクトやチーム間で使用することで、時間とコストを節約できます。 組織や業界によって異なるセキュリティとコンプライアンスのニーズは、時間とともに変化し進化していきます。このインフラストラクチャのデプロイメントを自動化することで、変更の追跡が容易になり、監査とコンプライアンスの維持が簡単になります。
AWS Audit Managerを活用したコンプライアンス評価の自動化
AWSは、コンプライアンス要件を満たすために役立つ数多くのサービスと機能を提供しています。このスキーマは、コンプライアンスの維持と自動化のための継続的なサイクルとして見ることができます。最初の部分はリスク評価で、組織の規制リスクを発見し、評価し、順位付けするプロセスです。これにより、それらの要件を満たすための技術的、組織的、契約上の管理の採用が促進されます。技術面では、AWS Audit ManagerがあなたのAWS使用状況から情報を収集し、監査に対応したレポートを提供するサービスとなります。AWS ConfigとAWS Security Hubを使用してセキュリティとコンプライアンスのチェックを作成し、そしてAWS Systems Managerを使用して自動修復を管理することができます。
Audit Managerの詳細に入る前に、AWS Artifactについて知っておく必要があります。 私たちがいつも言うように、セキュリティはAWSとお客様との共有責任であり、コンプライアンスも同様に共有責任です。AWS Artifactは、AWS側の対応に関する中心的なリソースです。ここでは、AWSおよびマーケットプレイスで製品を販売する独立系ソフトウェアベンダーからのセキュリティとコンプライアンスレポートにオンデマンドでアクセスできます。サードパーティの監査人によるコンプライアンスレポートの確認、契約の確認、承認、管理を行うことができます。
このプレゼンテーションでは、PCI DSSという広く知られたフレームワークを例に説明していきます。ここでご紹介する技術は、他のどのようなフレームワークにも適用できる可能性があります。PCI DSSは、アカウントデータを保護するための技術的および運用上の要件のベースラインを提供します。お客様のビジネスがクレジットカードを扱う場合、PCI準拠について考える必要がありますが、これはAWS Artifactで利用可能なリソースを使用して対応することができます。
AWS Artifactでは、PCI DSSパッケージにアクセスでき、主に2つの文書が含まれています。1つ目は「Attestation of Compliance」で、AWSがこの基準に対して正常に検証されたことを示すものです。2つ目の文書は「AWS Responsibility Summary」で、これによってカード所持者の環境を効果的に管理し、お客様の責任をより深く理解することができます。
では、お客様側での対応について見ていきましょう。AWS Audit Managerを使用することで、リスクとコンプライアンスの評価を簡素化するためにAWSの使用状況を監査することができます。このサービスは、AWSの使用データをコンプライアンス要件にマッピングします。最初に必要な作業は、PCIなどのフレームワークを選択または作成することです。次に実施したい評価の範囲を定義すると、サービスは選択したフレームワークに基づいて証跡を自動的に収集し、監査に対応したレポートを生成します。
このサービスはどこからデータを収集するのでしょうか？例えば、PCIの場合、お客様はEBSボリュームの暗号化ポリシーに関連するユーザーアクティビティを記録したログを監査人に示す必要があります。Audit Managerは、暗号化ポリシーの変更があったかどうかを確認するために、それらのAPI呼び出し（EBS API呼び出し）を含むCloudTrailログをスキャンします。その他の証跡のソースとしては、環境内の設定変更を捕捉するAWS ConfigやAWS Security Hubがあります。また、社内文書、メール、スクリーンショットなど、会社に関連する証跡を手動でアップロードすることもできます。Audit Managerはそれらのデータを取り込み、選択したフレームワークに基づいてレポートを生成します。
フレームワークは、一定期間にわたって環境内でテストされるコントロールを決定します。AWS Audit Managerには、GDPR、PCI、HIPAAなど、30以上の事前構築された評価フレームワークが用意されています。また、独自のカスタムフレームワークを最初から作成することも、既存のフレームワークの編集可能なコピーを作成することもできます。カスタムフレームワークを使用すると、特定のビジネス要件に合わせてコントロールをコントロールセットに整理することができます。これらのカスタムコントロールを別のリージョンやアカウントに複製すると、その基となるすべてのコントロールセットもコピーされます。
AWS ConfigとConformance Packsによるコンプライアンスチェックの実装
監査人に対して自社の環境がPCI準拠であることを示そうとすると、圧倒されてしまうかもしれません。そこで、これからデモでAudit Managerでアセスメントを作成する方法と、必要なエビデンスとその出所を理解する方法をご紹介します。 画面に最初に表示されるのがAudit Managerのダッシュボードです。アクティブなアセスメントの概要と、準拠しているコントロールと準拠していないコントロールが表示されています。
アセスメントを作成するには、「Create Assessment」をクリックして、 利用可能なフレームワークの中から、例えばPCIを選択します。私はすでにこれを作成済みなので、左側に移動して、 アクティブなアセスメントであるPCIバージョン4を開きます。ここには、情報が保存される S3バケット、アセスメントを作成した日付、そして下部にはこのフレームワークが求める実際の要件が表示されています。 これらはすべての要件と、各要件に適用されるすべてのコントロールです。例えば、アイデンティティ と認証に関する要件8を開くと、強力な認証に関する例として1つを開きます。すると、Audit Managerがすでに 多くの情報を収集していることがわかります。フォルダの1つを開くと、例えば4列目にデータソースがSecurity Hubから来ていることがわかり、この特定のコントロールは失敗していることがわかります。
このコントロールはS3バケットのSSL要件に関するものです。つまり、このコントロールについて何らかの対応が必要だとわかります。下にスクロールすると、いくつかのコントロールがConfig Security Hubから来ていることがわかり、その1つは合格しています。これは、 ロードバランサーでのHTTPS要件が適切に機能していることを示しており、このコントロールについては対応が不要です。
Audit Managerが複数のデータソースからエビデンスを取得することを確認したところで、エビデンスのソースの1つであるAWS Configを詳しく見てみましょう。 AWS Configを使って自動化されたコンプライアンスチェックを作成する方法を見ていきましょう。まず、AWS Configとは何かを理解しましょう。AWS Configは継続的な モニタリングとアセスメントのサービスで、リソースのインベントリを提供します。これらのリソースの設定変更を記録し、Systems Managerエージェントがインストールされている場合は、それらのリソース上の ソフトウェアの設定変更も記録できます。
このサービスが特に興味深いのは、セキュリティポリシー、業界のベストプラクティス、コンプライアンス基準への準拠を確認する ルールを作成できるからです。さらに、非準拠を自動的に修正する修復アクションを設定することもできます。 では、これはAudit Managerとどのように連携するのでしょうか？Cristinaが説明したように、AWS ConfigはAudit Managerのデータソースの1つです。まず、サービスとしてAWS Configを有効にする必要があります。次に、Audit Managerが必要とする特定のルールを有効にする必要があります。これらのルールを追加すると、コンプライアンス情報の収集を開始し、準拠しているか非準拠かをチェックし、この情報をエビデンスとしてAudit Managerに転送します。
これまでRulesについて何度か触れてきましたので、ここで詳しく説明させていただきます。 Rulesでは、リソースの望ましい状態、つまりコンプライアンスに準拠していると見なされる状態を具体的に定義します。Rulesには2つのタイプがあります。1つ目は、AWSが定義・管理しており、ユーザー側での設定がほとんど、あるいはまったく必要ないManaged Rulesです。2つ目は、 組織固有の要件に基づいて独自のルールをコード化できるCustom Rulesです。これをサポートするために、Rule Development Kitというオープンソースツールが用意されており、これらのルールの作成、テスト、管理に活用できます。
Audit Managerで表示されるConfig Ruleは、常にManaged Rulesのいずれかになります。ただし、Custom RulesもAudit Managerで使用できますが、これは手動の証拠収集をConfigで自動化するような形で代替することになります。Rulesには2つの評価モードがあります。1つ目はProactive評価、 そして2つ目はDetective評価です。Proactive評価では、リソースをデプロイする前にコンプライアンスへの準拠状況を評価します。これは、後で組織内で共有するリソーステンプレートを作成する際に、共有前にコンプライアンスに準拠していることを確認したい場合などに非常に便利です。Proactive評価が特に役立つもう1つの例として、CI/CDパイプラインとの統合があり、実際にデプロイする前にリソースのコンプライアンスをチェックできます。ただし、すべてのAWS Config Managed Rulesがこのモードをサポートしているわけではないことに注意が必要です。
このProactive評価モードは、CLI、SDK、またはCloudFormation Guardsを含むAWS Config APIを通じて機能します。私のCI/CDパイプラインでは、AWS Config APIを使用してリソースをデプロイする前にコンプライアンスをチェックしています。AWS CloudFormationを使用してデプロイする場合は、CloudFormation Hooksを設定して、実際のデプロイの前にコンプライアンスを事前にチェックできます。画面では、CLIでこのProactive評価モードを使用する例を見ることができます。Proactiveモードでの評価を開始するリクエストを送信し、リソースとリソースの詳細を提供すると、評価IDが出力されます。バックグラウンドでこの評価が実行され、その後、追加のリクエストを通じてこのリソース評価IDを使用してコンプライアンスに準拠しているかどうかを確認できます。
前のスライドに戻りますが、 このProactive評価モードはAudit Managerでは使用されません。なぜなら、Audit Managerでは既存のリソースがコンプライアンスに準拠しているかどうかを確認するためです。ただし、コンプライアンスの維持を考える上では、非常に興味深いモードと言えます。そして、もう1つのDetective評価モード では、リソースがデプロイされた後に評価を行います。これがAudit Managerで使用されるモードです。 評価の頻度について気になるかもしれませんが、これは私たち次第です。
評価を明示的にトリガーする必要があります。最初の評価は、 特定のルールを追加した時点で行われます。ルールを作成して追加すると、最初にコンプライアンスに準拠しているかどうかがチェックされます。その後は、評価を トリガーする必要があり、そのための方法がいくつかあります。まず、定期評価 があり、24時間ごとなど、チェックの頻度を自分で定義します。 もう1つの選択肢は設定変更で、ルールのスコープに一致するリソースの設定に変更があった場合に評価が実行されます。最後にハイブリッドモード があり、これは基本的に前述の2つのオプションを組み合わせたものです。
複数のリージョンやアカウントにわたってスケーリングする場合、AWS Config Conformance Packsを使用します。これはルールと修復アクションのコレクションで、デプロイすることができます。AWS Organizationsとうまく統合されており、Conformance Packsの興味深い点の1つは、AWSサービスの運用ベストプラクティスやPCIを含むコンプライアンスフレームワークのためのサンプルテンプレートを提供していることです。スライドの左側のスクリーンショットで見られるように、PCI DSSのための3つの異なるConformance Packsがあります。一番下がバージョン3を指し、上の2つがバージョン4に必要な追加項目を指しています。デプロイするリージョンに応じて、グローバルリソースを除外または含めることになります。これらのConformance PacksにはYAMLテンプレートが用意されていますが、使用する際には特定のニーズに合わせてカスタマイズすることを強くお勧めします。
AWS Security Hubを用いた脆弱性評価と自動修復の仕組み
PCIのConformance Packsだけでなく、異なるフレームワークを持っている可能性もあり、同じルールを複数回デプロイしたくはないでしょう。コストを節約するために、Conformance Packsをカスタマイズして、必要なルールだけを持つようにしましょう。より厳しい要件がある場合はルールを変更し、それらをベースとして構築できるテンプレートとして考えてください。さて、これを実際にどのように設定するかについて、Audit Managerからクイックデモを始めましょう。ここで様々な要件を確認し、コントロールの1つに移動します。
3.5 0.1を選び、異なるエビデンスソースをクリックして、AWS Configが必要なすべてのエビデンスソースをフィルタリングできます。かなりの数がありますので、その中の1つ - EBS encryption by default - を選んでみましょう。では、AWS Configに移動して、この特定のルールを設定してみましょう。
AWS Configでは、左側に異なるルールが表示されます。すでに設定されているルールの概要を確認できます。まだ何も設定していませんが、ルールを追加してみましょう。Managed RulesとCustom Rulesがあり、先ほど確認した識別子 - EBS encryption by default - を使用して、必要なルールを見つけることができます。また、異なる評価モードも確認できます。24時間ごとにコンプライアンスをチェックするように設定します。このルールを作成すると、バックグラウンドで先ほど説明した初期評価が実行され、コンプライアンス状態をチェックし、その後24時間ごとに繰り返されます。
では、すべてのルールを個別に追加したくないので、Conformance Packを見てみましょう。ここでConformance Packをデプロイできます。サンプルテンプレートがあり、自分でアップロードすることもできます。PCI DSSの運用ベストプラクティスを実装しようと思います。この場合、バージョン3.1です。名前を付けて、すべての手順を完了すると、バックグラウンドでこのConformance Pack内のすべての異なるルールが作成され、コンプライアンス評価が開始されます。最後に、どれだけうまくいったかのコンプライアンススコアと、どのルールがコンプライアントだったかどうかも確認できます。
以上でAWS Configのデータソースについての説明を終わります。ここからは、ChristinaがAWS Security Hubについて詳しく説明します。AWS Config がCustom Conformance Packsでより柔軟性を提供するのに対し、AWS Security Hubは最初から使える形でセキュリティとコンプライアンス情報の中心的な場所として機能します。それでは、Security Hubを使ってAWSの利用状況における脆弱性をどのように評価できるのか見ていきましょう。このサービスは、セキュリティのベストプラクティスチェックを継続的に実行し、AWSおよびサードパーティサービスからのセキュリティ関連の発見事項を集約して、自動化された対応を可能にします。
最上位層には、PCIなどのフレームワークに対する発見事項を集約して優先順位付けするオーバービュー機能があります。まとめると、PCIなどのコンプライアンス基準がSecurity Hubにすでに存在する場合、それが最も簡単な方法となります。Amazon Detectiveとの連携により発見事項を調査したり、Amazon EventBridgeとの連携で自動修復アクションを構築したりすることができます。Security Hubは 、Lauraが説明したAWS Configをはじめ、インテリジェントな脅威検出サービスであるAmazon GuardDuty、S3バケット上のPII情報を検出するサービスであるAmazon Macie、その他多くのツールからデータを収集します。
Security Hubは、異なるアカウント、サービス、さらにはサードパーティ製品からAWS環境に届くアラートを集約・優先順位付けし、それらの発見事項に単一の場所からアクセスできるようにします。このサービスは、PCIなどの業界標準にマッピングできるルールに対してセキュリティチェックを実行することで、独自の発見事項も生成します。ここでより詳しく見ていきましょう。セキュリティ標準とは、 規制フレームワーク、業界のベストプラクティス、または自社のポリシーに基づく要件のセットです。標準を有効にすると、Security Hubは、それに適用されるすべてのコントロールを自動的に有効にします。その後、このサービスはそれらのコントロールに対してセキュリティチェックを実行し、発見事項を生成します。標準を無効にすると、Security Hubは対応するコントロールに対するセキュリティチェックの実行を停止し、発見事項は生成されなくなります。
PCI DSS標準を使用することで、 カード所有者のデータを扱うリソースのセキュリティ脆弱性を発見することができます。重要な点として、AWS Security Hubは現在、アカウントレベルでコントロールのスコープを設定しているため、カード所有者データの保存、処理、または転送を行うすべてのアカウントでこれらのコントロールを有効にすることをお勧めします。
最初の話に戻りますが、 AWS Audit Managerは、Security Hubによって生成された発見事項をエビデンスの一形態として自動的に取り込み、CloudTrailログ、AWS Config情報、その他のソースからのエビデンスと組み合わせて、監査に向けたレポートを生成します。
デモで実際に見てみましょう。現在、AWS Audit Managerのダッシュボードを表示しています。例として、あるコントロールの1つに移動し、先ほどLauraがAWS Configで行ったように、エビデンスソースをフィルタリングして、今回はSecurity Hubを選択します。そこには多くのコントロールがあります。このエビデンスはSecurity Hubによって収集されており、例としてEC2.2というマッピングを見てみましょう。
では、Security Hub側の設定を見ていきましょう。まず最初に、AWS ConfigとSecurity Hubを有効にする必要があります。これらのサービスを有効にしたら、左側のコントロールに移動して、この例を探します。先ほどのEC2.2というコントロールですが、これはセキュリティグループのインバウンドとアウトバウンドのトラフィックの許可状況を確認するものです。ここにはまだデータが表示されていませんが、もちろんこれは最初にスタンダードを有効にする必要があるからです。セキュリティスタンダードに移動して、PCIを探し、このスタンダードを有効にしてみましょう。これにより、関連するすべてのコントロールが有効になります。セキュリティチェックが実行され、その結果としてFindingsが生成されます。また、必要な情報を収集するために、基盤となるAWS Configルールなども有効になります。しばらくすると、このサービスはセキュリティスコアを表示してくれます。
では、コントロールの1つがコンプライアンス違反になった場合はどうなるでしょうか？Laura、そのような場合はどうすればよいでしょうか？はい、ありがとうございます、Christina。では、修復を自動化するにはどうすればよいでしょうか？それには、AWS Systems Manager Automationドキュメントを使用します。AWS Systems Manager Automationは、AWS Systems Managerの機能の1つで、AWS リソース全体で一般的な反復的なIT運用管理タスクを自動化します。ワークフローは3つの主要なステップで構成されています。まず、修復に必要な手順を説明したドキュメントを作成する必要があります。これはJSONまたはYAMLで記述されます。AWSが事前に定義したドキュメントを使用することもできますし、独自のものを作成することもできます。お客様の一般的なユースケースに基づいて作成された既存のドキュメントを確認することを強くお勧めします。
Systems Manager Automationによる自動修復の実践と今後のステップ
次に、自動化を実行する必要があります。これは、コンソールを通じて手動でトリガーすることも、自動的にトリガーすることもできます。これが今回のユースケースで興味深い点です。最後に、自動化の監視とテストを行うことができます。では、先ほど触れた自動トリガーについて詳しく見ていきましょう。これを実現する方法の1つが、AWS Config修復アクションです。AWS Config修復アクションは、AWS Configで作成する各ルールのオプションとなります。修復アクションを追加し、ドキュメントを自動的に実行することができます。もう一度例を見てみましょう。これは、AWS Configのデモでお見せしたEBSの暗号化をデフォルトで有効にするルールの例です。このルールは、EBSボリュームのデフォルト設定が暗号化されているかどうかをチェックします。
この場合、暗号化されていないためコンプライアンス違反とみなされます。これを修正するには、EnableEbsEncryptionByDefault APIコールを実行する必要があります。このAPIコールを自動的に実行するAWS Systems Manager Automationドキュメントを作成したいと思います。
AWS Configでは、Manage Remediationに移動してRemediation Actionを追加することができます。左のスクリーンショットの下部を見ると、Automation Documentを選択できます。右側には既存のドキュメントが表示されており、これをRemediation Actionsに追加して修復を管理することができます。 ここでは、すべてのEBSボリュームが暗号化されていないというEBSのデフォルト設定があり、これは準拠していない状態ですが、これをチェックするAWS Config Ruleを設定しました。 非準拠が検出されると、自動的にこのAutomation Documentがトリガーされ、先ほど説明したAPI呼び出しを実行して修復を行います。これにより、EBSボリュームのデフォルト設定は暗号化された状態となります。
Security Hubについて、先ほど議論した例を見てみましょう。Control 2.2があり、 これはVPCのデフォルトセキュリティグループがインバウンドやアウトバウンドのルールを許可していないかをチェックします。左下に示されているように、2つのインバウンドルールと2つのアウトバウンドルールがありますが、これは望ましくない状態です。これを修復するために、 Security Group Revoke IngressとEgressという2つのAPI呼び出しを実行する必要があります。これを実行するAutomation Documentを見つける必要がありますが、幸いにも既存のドキュメントがあります。
右側に表示されているAWS-CloseSecurityGroupドキュメントには、より詳細な情報が含まれています。今すぐ全てを読む必要はありませんが、基本的には最初にインバウンドルールをチェックし、存在する場合は削除し、同様にアウトバウンドルールに対しても実行します。Christinaが説明したように、この修復の自動化はEventBridgeと連携して動作し、アカウントで特定のイベントが発生した際に自動的に修復アクションをトリガーすることができます。
この例で実際の動作を見てみましょう。準拠していないセキュリティグループがあり、 AWS Systems Managerでこの情報を収集します。これらのコントロールの多くは、バックグラウンドでAWS Configを使用してこの情報を収集しています。 このルールが非準拠を検出し、この情報をSecurity Hubに転送します。 Security Hubが失敗ステータスを示し、このコントロールのコンプライアンスステータスが 失敗の場合を監視するEventBridgeルールを設定する必要があります。その場合、Systems Manager Automationを実行します。 これによりバックグラウンドで様々なAPI呼び出しが実行され、準拠状態となります。これら全てが自動的に実行されます。
ここで一歩下がって全体像を見て、次のステップについて話し合いましょう。 AWS Audit Managerを使用して評価と証拠収集を自動化し、監査用のレポートを生成する方法を見てきました。また、AWS Security HubとAWS Configを使用してセキュリティとコンプライアンスのチェックを作成し、Systems Managerを使用してリスクに対する修復とアクションを実行する方法も確認しました。これらのサービスはマルチアカウント設定でうまく機能することを強調したいと思います。実際、私はマルチアカウント設定をお勧めしています。
アクションアイテムとして、ご利用可能なさまざまなコンプライアンスリソースをご確認いただければと思います。1つ目のQRコードは「Practical Data Protection and Risk Assessment for Sensitive Workload」というワークショップ用です。2つ目のリンクはAWSの公式コンプライアンスドキュメント、そして3つ目は私とLauraが執筆したブログ記事となっています。コンプライアンスの自動化についてサポートが必要な場合は、担当のAccount ManagerやSolutions Architectにお気軽にご相談ください。ご質問がございましたら、Expoの Security Activation スペースで専門家が対応させていただきます。本セッションにご参加いただき、ありがとうございました。セッションアンケートにもぜひご協力ください。ご質問がありましたら、私たちがお答えいたします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion