この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS環境のガードレール作成に役立ちそうな以下アップデートの紹介です！
Security Hub の自動修復ソリューションとは？
Security Hub の自動修復ソリューション の実態は AWSソリューション実装で公開されている AWS提供のCFnテンプレート です。
このテンプレートを展開することで、Security Hub を起点にした自動修復の仕組みを簡単に構築できます。 以下の構成図のように「特定チェックに合格しなかったリソース」をトリガーに修復アクションを 実行します。
– 図: AWS Security Hub Automated Response and Remediation | Implementations | AWS Solutions
この「特定チェック」のサポート範囲が、今までは CIS AWS Foundationsベンチマーク のみでした。(↓のブログを参照)
今回のアップデート
Security Hub の自動修復ソリューションが新たに 『基礎セキュリティのベストプラクティス』 もサポートするようになりました。
以下 11項目の自動修復を実装できます。
- [AutoScaling.1] ロードバランサーに関連付けられた Auto Scaling グループはロードバランサーのヘルスチェックを使用する必要があります
- [CloudTrail.1] CloudTrail を有効にして、少なくとも 1 つのマルチリージョントレイルで設定する必要があります
- [CloudTrail.2] CloudTrail では、保管時の暗号化を有効にする必要があります
- [Config.1] AWS Config を有効にする必要があります
- [EC2.1] EBS スナップショットはパブリックであってはなりません。誰でも復元できるかどうかによって決まります。
- [EC2.2] VPC のデフォルトのセキュリティグループはインバウンドトラフィックとアウトバウンドトラフィックを許可しない必要があります
- [EC2.7] EBS のデフォルト暗号化を有効にする必要があります
- [Lambda.1] Lambda 関数は、他のアカウントによるパブリックアクセスを禁止する必要があります
- [RDS.1] RDS スナップショットはプライベートにする必要があります
- [RDS.6] RDS DB インスタンスおよびクラスターに対して拡張モニタリングを設定する必要があります
- [RDS.7] RDS クラスターでは、削除保護を有効にする必要があります
やってみる(ソリューションの展開)
こちらのガイド どおりに、進めていきます。 前提条件として Security Hub の有効化は済ませておきます。
※注意1
Security Hubをマルチアカウント利用している場合は、後述する Step 1, Step 2, Step 3.1
は 管理アカウント上で行います。
※注意2
既に以前の(古い)ソリューションを展開している場合は、それを一度アンインストールする必要があります。 アンインストールの手順は以下ドキュメントを参照ください。
Step 1. スタック展開
ガイドのページの Step 1. Launch the stack に
にある Launch Solution をクリックすると CFnスタック作成画面に遷移します。
※今回は東京リージョンで展開します。その場合は遷移先画面でリージョンを切り替えるのを忘れずに
特にパラメータの指定などありません。展開します。(おおよそ数分〜10分程度かかります)
Step 2. ポートフォリオの許可設定
ポートフォリオのアクセス権を編集して、私が展開できるようにします。
Service Catalog へ向かいます。 [管理者 > ポートフォリオ] に
Security Hub Playbooks(SO0111) ができているので、選択します。
[グループ、ロール、またはユーザーの追加] を選択して、IAMリソースを追加します。 (今回は 自身のIAMロールを追加)
Step 3.1: プレイブックの展開 その1
Service Catalog の [製品] ページに向かいます。
AFSBP(AWS Foundational Security Best Practices) 製品を起動します。
パラメータは以下のようになっています。
各チェック項目に対して
Installation(導入するか) と
AutoTrigger(検出結果をトリガーに自動修復を実行させるか)
を指定できます。
今回はひとまず全てのチェック項目をインストール、 AutoTrigger=Disabled としました。
パラメータを指定して起動しましょう。
Step 3.2: プレイブックの展開 その2
このステップのテンプレートは 修復を行う全てのアカウント(管理アカウント含) に展開する必要があります。 必要に応じて CFn StackSets など活用しましょう。
ガイド の Member account deployment – AFSBP v1.0.0 章にある View Template のURLをコピーしておきます。
コピーしたURLを指定して CFnスタックを作成しましょう。
パラメータは以下のようになっています。
「特定のメンバーアカウントはこの修復を実行させたくない」用途がある場合は、
それぞれパラメータの値を NOT Available としましょう。
加えて AdminAccountNumber パラメータには
Service Catalog製品を展開したアカウント(管理アカウント)のID を入力します。
以上でソリューションの展開は完了です。
やってみる(自動修復)
今回は [EC2.2] VPC のデフォルトのセキュリティグループはインバウンドトラフィックとアウトバウンドトラフィックを許可しない必要があります
の自動修復を試してみます。
対象のセキュリティグループはこちら(↓)。インバウンドとアウトバウンドを全て許可しています。
# aws ec2 describe-security-groups --filters Name=group-id,Values=sg-07f2xxxxxxxxxxxxx --output yaml
SecurityGroups:
- Description: default VPC security group
GroupId: sg-07f2xxxxxxxxxxxxx
GroupName: default
IpPermissions:
- IpProtocol: '-1'
IpRanges:
- CidrIp: 0.0.0.0/0
Ipv6Ranges: []
PrefixListIds: []
UserIdGroupPairs: []
IpPermissionsEgress:
- IpProtocol: '-1'
IpRanges:
- CidrIp: 0.0.0.0/0
Ipv6Ranges: []
PrefixListIds: []
UserIdGroupPairs: []
OwnerId: '123456789012'
VpcId: vpc-0311xxxxxxxxxxxxxSecurity Hub の [EC2.2] コントロールの画面に向かいます。
修復したいリソースを選択して [アクション > AFSBP EC2.2] を選択します。修復が始まります。
しばらく待った後に確認すると、セキュリティグループのインバウンド/アウトバウンドが全て削除されていました。
# aws ec2 describe-security-groups --filters Name=group-id,Values=sg-07f2xxxxxxxxxxxxx --output yaml
SecurityGroups:
- Description: default VPC security group
GroupId: sg-07f2xxxxxxxxxxxxx
GroupName: default
IpPermissions: []
IpPermissionsEgress: []
OwnerId: '123456789012'
VpcId: vpc-0311xxxxxxxxxxxxx▼ ログ確認
CloudWatch Logs に SO0111-SHARR-Orchestrator-AFSBP という項目があり、
そこで実行ログを確認できます。
※ AFSBPの自動修復は Step Functions で実装されていました。
おわりに
以上、 Security Hub の自動修復ソリューションのアップデート紹介でした。 改めて今回のアップデートで自動修復が可能になったチェック項目を記載します。
- [AutoScaling.1] ロードバランサーに関連付けられた Auto Scaling グループはロードバランサーのヘルスチェックを使用する必要があります
- [CloudTrail.1] CloudTrail を有効にして、少なくとも 1 つのマルチリージョントレイルで設定する必要があります
- [CloudTrail.2] CloudTrail では、保管時の暗号化を有効にする必要があります
- [Config.1] AWS Config を有効にする必要があります
- [EC2.1] EBS スナップショットはパブリックであってはなりません。誰でも復元できるかどうかによって決まります。
- [EC2.2] VPC のデフォルトのセキュリティグループはインバウンドトラフィックとアウトバウンドトラフィックを許可しない必要があります
- [EC2.7] EBS のデフォルト暗号化を有効にする必要があります
- [Lambda.1] Lambda 関数は、他のアカウントによるパブリックアクセスを禁止する必要があります
- [RDS.1] RDS スナップショットはプライベートにする必要があります
- [RDS.6] RDS DB インスタンスおよびクラスターに対して拡張モニタリングを設定する必要があります
- [RDS.7] RDS クラスターでは、削除保護を有効にする必要があります
これら 自動修復の仕組みは自前で作ろうとするとかなり大変です。 AWSのソリューションとして提供されているため、作り込み・管理の手間が省けます。 素敵なソリューションなのでぜひ導入しましょう。
完全自動修復(AutoTrigger=ENABLED)にする際は、事前に影響範囲を把握しておきましょう。
例えば [EC2.2] では、事前にデフォルトセキュリティグループが使われていないことを
確認しておかないとワークロードに影響が出る可能性があります。
また、何かしらの権限不足で修復に失敗した場合、
完全自動修復(AutoTrigger=ENABLED)としていると何度も修復を試みることになり
思わぬ課金が発生する可能性があります。事前のテストや結果のモニタリングはしっかりとしておきましょう。
参考
- AWS Documents
- DevelopersIO
2
