AWS Configとは
AWSリソースやオンプレミスサーバの設定変更管理、変更履歴のモニタリングを行うためのサービス。
以下のようなことが実現できる。
- Configルールと呼ばれる、事前に定義した「あるべき設定」と実際の設定との乖離を評価すること
- 変更の発生時にCloudWatch Eventsをトリガしたり、SNSを用いてメール通知すること
- 変更履歴の記録をコンプライアンス監査やセキュリティ分析用の資料として利用すること
Configルール
AWSアカウント内の各設定がルールに準拠しているかどうかチェックするために定義するもの。
以下のようなルールが設定できる。
- EBSが暗号化されているか
- CloudTrailが有効化されているか
- S3バケットのポリシーが”パブリック読み書き可能”になっていないか
- セキュリティグループで22番ポート（SSH）がパブリック公開されていないか
- 指定したタグがリソースに設定されているか
- 指定されたAMIが使用されているか
など（上記は一例）
マネージドルールとカスタムルール
Configルールには以下の2種類がある。
- マネージドルール：AWS側で予め用意されており、すぐに実装可能なルール。
- カスタムルール：Lambda関数を使用して自由にカスタムできるルール。
マネージドルールは現時点でも100個以上あり、基本的なセキュリティチェックを行いたい場合は、まずマネージドルールから検討すると良い。
カスタムルールは自由度が高い反面、Lambda関数内でチェックロジックを作成する必要があるため、実装するには手間がかかってしまう。
実際のユースケース
Configを使用した非準拠リソースの自動修復
例えば、"CloudTrailを有効化する"というルールを定義しているにもかかわらず、オペレーションミスによりCloudTrailが無効化されてしまった場合、以下の手順で自動修復が可能。
1.Configの管理画面にアクセス
2.自動修復を行いたいConfigルールをクリック
3.「修復の管理」から「AWS-EnableCloudTrail」を選択
4.自動修復「はい」のラジオボタンを選択
5.「保存」をクリック
6.アクションステータスが「アクションが正常に実行されました」となったことを確認
※詳しい手順は以下に記載
AWS Config Rules による非準拠 AWS リソースの修復
高度なクエリ
AWSアカウント内の設定情報に対してSQLを実行し、情報を確認することが可能。
例えば以下のクエリを「Configの高度なクエリ」から実行すると、インスタンスタイプ別のEC2の数を確認することができる。
SELECT configuration.instanceType, COUNT(*)
WHERE resourceType='AWS::EC2::Instance'
GROUP BY configuration.instanceType
※使用できるクエリの例は以下にも記載あり
クエリ例
参考文献