Amazon Web Services ブログ
Category: Security, Identity, & Compliance
エージェンティック AI への備え: 金融サービスにおけるセキュリティアプローチ
金融サービスでエージェンティック AI をデプロイするには、AI 固有のリスクに対処する追加のセキュリティ統制が必要です。この記事では、説明可能性と説明責任を支える包括的なオブザーバビリティときめ細かなアクセス制御に焦点を当て、7 つの中核的な設計原則を説明します。さらに、Amazon Bedrock AgentCore や Amazon CloudWatch を活用した監視、最小権限、ガードレール、マルチエージェントワークフローの管理など、規制要件を満たしながら安全に導入するための実装ガイダンスを紹介します。
エージェンティック AI システムのための 4 つのセキュリティ原則
AWS が NIST CAISI の情報提供依頼 (RFI) に提出した回答を基に、エージェンティック AI の 4 つのセキュリティ原則を紹介します。4 つの原則は、セキュアな開発ライフサイクル、従来のセキュリティ制御の継続適用、エージェントの外部に置く決定論的な制御 (セキュリティボックス)、評価に基づく段階的な自律性の拡大です。さらに、Amazon Bedrock AgentCore によるコンピューティングの分離、アイデンティティとアクセス管理、ポリシーの適用、オブザーバビリティといったアーキテクチャの構成要素も説明します。
プライベートアクセスでデータ境界を AWS マネジメントコンソールまで拡張
AWS マネジメントコンソールプライベートアクセスが、インターネット接続のない VPC に対応し、一般提供を開始しました。認証フロー、静的アセット、コンソール専用 API を含むコンソールトラフィックを、AWS PrivateLink の VPC エンドポイント経由でルーティングできます。この記事では、VPC エンドポイントポリシーとサインイン用のリソースコントロールポリシー (RCP) を組み合わせてデータ境界を強化する方法を説明します。パイロット導入の手順と考慮事項も紹介します。
AWS Weekly Roundup:数字で見るプライムデー2026、クロード・ハイク 5.5、Amazon Nova 2.5 Sonic など (2026 年 10 月 13 日)
数字の中には、しばらく向き合ってみないと想像しにくいものもあります。2026 年 10 月 5 日週、プライム […]
AWS Continuum で実現するデプロイごとのペネトレーションテスト
従来は定期的な診断で行われていたペネトレーションテストを、CI/CD パイプラインのデプロイ後ゲートとして組み込む方法を紹介します。AWS Continuum for penetration testing は、直前にデプロイした変更にスコープを限定し、AI エージェントを使用して悪用可能な脆弱性を確認します。そのため、デプロイのたびに高速かつ低コストで実行できます。OIDC フェデレーションによる IAM ロールの設定、GitHub Actions のワークフロー例、レポート専用モードからブロック運用へ移行する際の注意点も説明します。
Kiro CLI でセキュリティ調査を迅速化
Kiro CLI を使用して、「AWS セキュリティインシデント対応ガイド」のフレームワークに沿ってセキュリティ調査を迅速化する方法を紹介します。自然言語のプロンプトで Amazon GuardDuty の検出結果をトリアージし、EC2 インスタンスや IAM 権限を分析します。さらに、隔離用セキュリティグループによる封じ込め、フォレンジックスナップショットによる証拠保全、AWS CloudTrail ログ分析を進めます。Amazon SNS と Amazon EventBridge による自動アラートの構築や、ステアリングファイルによる再利用可能な調査ワークフローの作成も解説します。
Kiro と Amazon Q でセキュリティポスチャを強化する 5 つの方法
この記事では、Kiro と Amazon Q Developer を使用して AWS のセキュリティポスチャを強化する 5 つの方法を紹介します。ステアリングファイルとルールによる永続的なコンテキストでセキュリティ標準を組み込む方法をはじめ、MCP サーバーを活用した AWS Security Hub の検出結果のトリアージ、Infrastructure as Code (IaC) の修復、AWS Well-Architected フレームワークのセキュリティの柱に沿ったレビュー、サービスコントロールポリシー (SCP) の作成を迅速化する手法を説明します。あわせて、人間による検証の重要性と段階的な導入の進め方も解説します。
AWS CloudTrail を使ったインシデント調査・対応ガイド – パート 2
本ガイドのパート 2 では、ウェブアプリケーションの SSRF の脆弱性を起点に、IMDSv1 からの認証情報の窃取、リージョンホッピングを経て Amazon Bedrock が不正使用されたマルチステージ攻撃を、AWS CloudTrail のログから分析します。userIdentity、readOnly、awsRegion などの注目すべきフィールドとインシデント対応チェックリストを紹介し、IMDSv2 の強制、最小権限、モデル呼び出しのログ記録といった強化策と、脅威アクターの回避手法も解説します。
AWS CloudTrail を使ったインシデント調査・対応ガイド – パート 1
AWS CloudTrail ログには、疑わしいアクティビティを調査するために必要な証拠が含まれています。このパート 1 では、AWS の Security Incident Response Team (SIRT) が実践する調査手法を、2 つの実際のシナリオに沿って紹介します。1 つは、設定ミスのあるクロスアカウントアクセスが悪用され、ランサムウェアとの関連が疑われる Amazon S3 データ削除に至った事例です。もう 1 つは、多要素認証 (MFA) のないコンソール認証情報が悪用され、AWS CloudFormation と AWS CloudShell で暗号通貨マイニングが行われた事例です。重要なフィールドの読み解き方、調査の優先順位、対応チェックリスト、予防策を解説します。
AWS STS のセッショントークンのサイズ制限を簡素化、サイズのモニタリングにも対応
AWS STS のセッショントークンのサイズ制限が 4,096 バイトの単一の制限に簡素化され、セッションポリシーとセッションタグに使用できる容量が拡大しました。トークンサイズは API レスポンス、Amazon CloudWatch メトリクス、AWS CloudTrail イベントで報告されます。また、MinimumSessionTokenSize パラメータを使用して、インフラストラクチャが処理できるトークンの最大サイズを検証できます。この記事では、変更点と影響に加え、ロードバランサーやデータベースなどトークンを扱うシステムで推奨される対応を説明します。








