この記事では、MICROSOFT SENTINELが SAML ロールを引き受けるユーザー、またはアラートがトリガーされたときに AWS IAM アカウントで自動アクションを実行できるように AWS 環境を構成する方法について説明します。 攻撃の中断 では、信頼度の高いシグナルを使用して、侵害された資産を封じ込め、AWS の ID に対するアクションなど、攻撃による損害を制限します。 開始する前に、必要な AWS とMicrosoft Sentinelの前提条件が満たされていることを確認します。
前提条件
開始する前に、次の前提条件が必要です。
- 管理者特権を持つアクティブな AWS アカウントがあります。
- Microsoft Sentinel分析ワークスペースは、統合セキュリティ運用ポータルに接続されています。
- AWS Connector for Microsoft Sentinelがデプロイされ、有効になっている
- AWS CloudTrail ログが Microsoft Sentinel に取り込まれています。「Microsoft Sentinelを Amazon Web Services に接続して AWS サービスのログ データを取り込む」を参照してください。
- AWS では、MICROSOFT SENTINELが IAM アカウントに対してアクションを実行できるように、適切な IAM ロールとアクセス許可が構成されています。
手順 1: 統合のために AWS を準備する
次のタスクを実行して、Microsoft Sentinel統合のために AWS 環境を準備します。
1.1 Microsoft Sentinel用の専用 IAM ロールを作成する
- AWS Management Console で新しい IAM ロールを作成します。
信頼できるエンティティとして AWS サービス を選択し、一時的なプレースホルダーとして EC2 を選択します。 この信頼関係は、「信頼関係の構成」で正しいMicrosoft Sentinel プリンシパルに置き換えます。
ロールに次の IAM ポリシーをアタッチします。 このポリシーは、攻撃中断アクションの IAM ユーザーポリシーとロールポリシーを管理するために必要なアクセス許可をMicrosoft Sentinel付与します。 必要に応じて <YOUR_ACCOUNT_ID> を置き換えます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:DeleteRolePolicy", "iam:PutUserPolicy", "iam:AttachUserPolicy", "iam:ListUserPolicies", "iam:PutRolePolicy", "iam:GetUser", "iam:DetachUserPolicy", "iam:GetRolePolicy", "iam:DeleteUserPolicy", ], "Resource": "*" } ] }
1.2 信頼関係を構成する
IAM ロールの カスタム信頼ポリシー を作成します。
次の信頼ポリシーを使用して、Microsoft Sentinel統合プリンシパルを指定します (<YOUR_AZURE_SUBSCRIPTION_ID>を実際のAzure サブスクリプション ID に置き換えます)。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com",
"AWS": "arn:aws:iam::<YOUR_AZURE_SUBSCRIPTION_ID>:root"
},
"Action": "sts:AssumeRole"
}
]
}
手順 2: CloudTrail を有効にする
すべての AWS リージョンで CloudTrail ログを有効にして、Microsoft Sentinelが必要なアクティビティ データを受信できるようにします。
AWS コンソールで、 CloudTrail に移動します。
CloudTrail が有効になっていて、すべてのリージョンでログ記録がアクティブになっていることを確認します。
手順 3: Microsoft Sentinelで AWS コネクタをデプロイして有効にする
AWS 環境からログ データを受信できるように、Microsoft Sentinelで AWS S3 データ コネクタをデプロイして有効にします。 開始する前に、Amazon Web Services S3 コネクタがデータ コネクタ ギャラリーに表示されるように、Microsoft Sentinelのコンテンツ ハブから Amazon Web Services ソリューションがインストールされていることを確認します。
Azure portalで、[Microsoft Sentinel > データ コネクタ] に移動します。
データ コネクタ ギャラリーから [Amazon Web Services S3 ] を選択します。
「Microsoft Sentinelをアマゾン ウェブ サービスに接続する」の手順に従って AWS サービス ログ データを取り込み、AWS 環境を設定し、Microsoft Sentinelに接続します。
AWS 環境から S3 ログ通知を受信する IAM ロール ARN と Amazon SQS キュー URL を指定します。 これらの値は、前の手順で説明したコネクタのセットアップ中に作成されます。
手順 4: 統合を検証する
AWS コネクタの統合が正しく動作していることを確認するには、次のチェックを使用します。
Microsoft Sentinelで、コネクタの状態が [接続済み] であることを確認します。
Log Analytics ワークスペースでコネクタとインジェストの正常性状態を報告する SentinelHealth 診断テーブルを使用して、ログ インジェストとコネクタの正常性を確認します。 また、AWS SQS キューの状態を確認して、ログ通知が処理されていることを確認します。
AWS では、CloudTrail イベントと GuardDuty イベントがMicrosoft Sentinelに送信されていることをチェックします。
手順 5: 統合をテストする
次のテストを実行して、自動攻撃中断応答アクションが期待どおりに動作することを確認します。
AWS でテスト アラートをトリガーします (たとえば、シミュレートされた資格情報の侵害)。
Microsoft Sentinelが、影響を受ける IAM アカウントで構成されたアクションを実行できることを確認します。
AWS の監査ログとMicrosoft Sentinelを確認して、正常な実行を確認します。
手順 6: 監視と保守
時間の経過と同時に統合を監視および維持するには、次のプラクティスを使用します。
- AWS の IAM ロールのアクセス許可と監査ログを定期的に確認します。
- AWS 環境Microsoft Sentinel変更を反映するために、必要に応じて分析ルールと自動化プレイブックを更新します。
- Microsoft Sentinel ポータルでアラートと応答アクションを監視します。
次のスクリプトでは、AWS とMicrosoft Sentinelを統合して攻撃の中断を可能にするために、AWS IAM ロールと OIDC プロバイダーの設定を自動化します。
次の Bash スクリプトは、MICROSOFT SENTINEL統合のための AWS OIDC プロバイダーの構成と IAM ロールの作成を自動化します。 実行する前に、AWS CLI がインストールされ、IAM 管理アクセス許可を持つアカウントで認証されていることを確認します。 コード スニペットを bash ファイルとして保存して実行します。
#!/bin/bash
# AWS Sentinel OIDC Setup Script
# Configures IAM roles and policies for Microsoft Sentinel integration
set -e # Exit on error
# Color codes for output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
CYAN='\033[0;36m'
NC='\033[0m' # No Color
ms_federated_endpoint="sts.windows.net/33e01921-4d64-4f8c-a055-5bdaffd5e33d"
actions_audience="api://b7c1e142-0933-4310-ba00-8b28878bfece"
role_name="OIDC_Actions_Sentinel"
policy_name="SentinelActionsPolicy"
# Verify AWS credentials are configured
echo -e "${CYAN}Verifying AWS credentials...${NC}"
if ! account_id=$(aws sts get-caller-identity --query Account --output text 2>&1); then
echo -e "\n${RED}ERROR: AWS credentials not configured or invalid${NC}"
echo -e "${RED}Details: $account_id${NC}"
echo -e "\n${YELLOW}Please authenticate using one of these methods:${NC}"
echo -e "${YELLOW} 1. Run 'aws configure' to set up credentials${NC}"
echo -e "${YELLOW} 2. Set AWS environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)${NC}"
echo -e "${YELLOW} 3. Use 'aws sso login --profile <profile-name>' for SSO${NC}"
exit 1
fi
echo -e "${GREEN}✓ AWS authenticated (Account: $account_id)${NC}"
trust_policy_document=$(cat << EOM
{
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::$account_id:oidc-provider/$ms_federated_endpoint/"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"$ms_federated_endpoint/:aud": "$actions_audience",
"sts:RoleSessionName": "MicrosoftSentinel_$account_id"
}
}
}
]
}
EOM
)
permissions_policy_document=$(cat << EOM
{
"Statement": [
{
"Sid": "SentinelActionsPermissions",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:DeleteRolePolicy",
"iam:PutUserPolicy",
"iam:AttachUserPolicy",
"iam:ListUserPolicies",
"iam:PutRolePolicy",
"iam:GetUser",
"iam:DetachUserPolicy",
"iam:GetRolePolicy",
"iam:DeleteUserPolicy",
"s3:PutBucketPublicAccessBlock"
],
"Resource": "*"
}
]
}
EOM
)
aws iam add-client-id-to-open-id-connect-provider --open-id-connect-provider-arn arn:aws:iam::$account_id:oidc-provider/$ms_federated_endpoint/ --client-id $actions_audience
aws iam create-role --role-name $role_name --assume-role-policy-document "$trust_policy_document" || aws iam update-assume-role-policy --role-name $role_name --policy-document "$trust_policy_document"
aws iam put-role-policy --role-name $role_name --policy-name $policy_name --policy-document "$permissions_policy_document"