Amazon Web Services ブログ
Category: Intermediate (200)
AWS Security Incident Response: インシデント対応ライフサイクルを加速するためのお客様の取り組み
AWS Security Incident Response がインシデント対応ライフサイクルのあらゆる段階をどのように加速するのかを、ランサムウェアの可能性がある不審なアクティビティへの対応シナリオを通じて紹介します。Amazon GuardDuty や AWS Security Hub と統合した自動トリアージ、AWS Systems Manager による自動封じ込め、AWS Security Incident Response Engineering (SIRE) チームへのエスカレーション、インシデントケース ID を使ったタグ付けなど、検出から解決までの流れを解説します。あわせて、アラート疲れを軽減し、対応時間を短縮する方法も説明します。
Amazon Linux で npm と pip のパッケージ更新を安全にする方法
npm や PyPI のパッケージは、公開直後の数時間に最もサプライチェーンのリスクが高くなります。この記事では、Amazon Linux 2023 で npm の min-release-age と pip の uploaded-prior-to を使用して 1 日の依存関係のクールダウンを設定し、予期しないパッケージのインストールを防ぐ方法を紹介します。また、npm audit と pip-audit で特定したパッケージに限ってクールダウンをオーバーライドし、セキュリティ修正を適用する方法も説明します。
脅威の手口を解説: サブドメイン乗っ取りの仕組みと対策
このブログ記事では、脅威アクターがダングリング DNS レコードを悪用し、トラフィックを攻撃者が管理するリソースにリダイレクトするサブドメイン乗っ取りの仕組みと対策を説明します。S3、CloudFront、Elastic Beanstalk など乗っ取りの対象になり得るリソースを整理し、具体的なシナリオを分析します。さらに、AWS Config カスタムルールによるプロアクティブな検出、DNS レコードを先に削除する標準作業手順、Security Hub や SNS による通知と修復の方法を紹介します。
AWS セキュリティサービスでアクセスキーの漏えいリスクを最小限に抑える実践的な手順
漏えいした長期的な認証情報 (アクセスキー) は、AWS Customer Incident Response Team (CIRT) が観測したセキュリティインシデントで、現在も脅威アクターに最も多く使われる侵入経路です。この記事では、Amazon Q Developer や AWS IAM Access Analyzer を使用して、漏えいしたキーや未使用のアクセスを検出する方法を紹介します。さらに、SCP と RCP によるデータ境界の確立、Amazon Inspector や AWS WAF によるランタイム環境の保護、Secrets Manager によるキーの自動ローテーション、Amazon GuardDuty による異常な IAM アクティビティの検出を取り上げます。これらを組み合わせた多層防御の実践的な手順を説明します。
Amazon S3 Access Points で Amazon FSx for NetApp ONTAP 上のデータに AWS サービスからゼロコピーでアクセスする
半導体の検証チームが毎晩生成する大量の EDA ログを、データを移動せずに AI で分析するアーキテクチャを紹介します。Amazon S3 Access Points を使って Amazon FSx for NetApp ONTAP 上のログに S3 API でアクセスし、Amazon Bedrock AgentCore と Amazon Quick により、リグレッションテストで失敗した原因の切り分けを自然言語の質問で行います。
Kiro CLI でセキュリティ調査を迅速化
Kiro CLI を使用して、「AWS セキュリティインシデント対応ガイド」のフレームワークに沿ってセキュリティ調査を迅速化する方法を紹介します。自然言語のプロンプトで Amazon GuardDuty の検出結果をトリアージし、EC2 インスタンスや IAM 権限を分析します。さらに、隔離用セキュリティグループによる封じ込め、フォレンジックスナップショットによる証拠保全、AWS CloudTrail ログ分析を進めます。Amazon SNS と Amazon EventBridge による自動アラートの構築や、ステアリングファイルによる再利用可能な調査ワークフローの作成も解説します。
責任ある AI ガバナンス: お客様が ISO/IEC 42005:2025 との整合を図れるよう AWS が支援する方法
生成 AI の導入が急速に進む中、組織には責任ある AI ガバナンスへの体系的なアプローチが求められています。本記事では、国際規格 ISO/IEC 42005:2025 に基づく AI システム影響評価の概要と、既存のリスク管理プロセスへの統合方法を解説します。再評価のトリガーやトリアージを含む評価プロセスの構築方法も取り上げます。また、ISO/IEC 42001 認証の取得における ISO/IEC 42005 の役割や、AWS Well-Architected Responsible AI Lens をはじめとする規格との整合を支援する AWS のツールも紹介します。
新しいコンプライアンスガイド「ISO/IEC 42001:2023 on AWS」を公開 – AI マネジメントシステムの設計と運用を支援
AWS は、コンプライアンスガイド「ISO/IEC 42001:2023 on AWS」を公開しました。このガイドでは、AWS サービスを使用して AI マネジメントシステム (AIMS) を設計、運用する方法を説明します。ISO 42001:2023 の箇条 4~10 と附属書 A の管理策を AWS サービスにマッピングし、AI ワークロードへの AWS 責任共有モデルの適用方法も解説します。エビデンス収集の自動化や、Infrastructure as Code を活用して AI コンプライアンス活動を運用に組み込む方法も取り上げ、AI ガバナンスの強化と認証審査への準備を支援します。
AWS で実現する AI 主権
AI 主権は、データ主権と運用主権を基盤に、AI の出力で文化的規範や価値観、現地の言語を守るという新たな考慮事項を加えた概念です。本記事では、チップ、デプロイ先、モデルを自由に選べる AI スタック全体でのコントロールと選択肢を紹介します。また、Meltemi や SEA-LION などの現地の言語に対応したモデルの支援、AWS Nitro System による検証可能なデータアクセスのコントロール、ISO/IEC 42001 認証による透明性と保証についても説明します。
AI を活用した脆弱性検出ハーネス (パート 1 構築編): 3 層パイプラインによる検出結果の絞り込み
脆弱性スキャナーの検出結果は、手動のトリアージでは処理しきれないほど増え続けています。この記事では、AI を活用した脆弱性検出ハーネスを紹介します。複数スキャナー間の一致、AST による構造検証、IaC テンプレートを用いたデプロイコンテキストの 3 層で検出結果をフィルタリングし、悪用可能性の証拠を備えた優先順位付きの少数の検出結果に絞り込みます。パイプラインの構築から得られた 4 つの原則と、段階的な導入手順も解説します。









