【AWS】Config ルールを設定する

Config ルールとは

Config ルールとは、AWS Configの機能の一つで、AWSアカウント内の設定が適切であるかを自動で確認してくれる機能です。
例えば、EBS暗号化必須のルールを設定したとします。仮に非暗号化のEBSが作成されたとしたら、これはルール違反として検知することができます。
つまり、端的に言うとルール違反したAWSリソースを迅速に見つけてくれる機能なのです。この機能を導入することにより、AWS環境が社内のコンプライアンスやルールに従っているかどうかを評価することができるようになります。

Configルールの設定

それでは、ここからはConfig ルールの設定をしていきましょう。
今回は簡単なルール設定をしていこうかと思います。
AWSが始めから用意しているプリセットルールを使ったセキュリティグループに関するルールを設定したいと思います。
セキュリティグループのルールの中にSSHの全開放(0.0.0.0/0)があった場合にルール違反として検出するよう設定をしていきます。

AWSマネージメントコンソールから「Config」 > 左メニュー「ルール」をクリック。「ルールを追加」ボタンをクリックします。

ルールタイプを選択します。プリセットルールを使用しますので、
「AWSによって管理されるルールの追加」をチェックします。
※余談ですが、下記の画像からわかるように、335個のプリセットルールが用意されていますね。

検索窓に「ssh」と入力します。検出結果の中から「restricted-ssh」を選択し、「次へ」をクリック

「名前」、「Description」はデフォルトのまま

変更範囲は、デフォルトのまま「リソース」を選択、
リソースの詳細設定も、デフォルトのまま「Security Group」が選択されている状態。頻度もデフォルトのままにします。

最下段の「次へ」をクリックし、最終確認画面が出るので「保存」をクリックします。
これでルール設定は完了です。

しばらくすると、Configルール一覧の「検出コンプライアンス」欄が
「準拠」になりました。現時点で違反は無いようですね。

ルール違反検出確認

ここからは、セキュリティグループをSSH全開放し、ルール違反を検出させたいと思います。

下記画像のように、セキュリティグループをSSH：0.0.0.0/0で登録します。

少し待つと、下記画像のようにConfigルール一覧で「非準拠リソース」として表示されました。違反が検出されましたね。

自動修復機能の設定

ここからは自動修復機能を設定してみたいと思います。SSHの全開放(0.0.0.0/0)があった場合にルール違反として削除する自動修復を設定しようと思います。

IAMポリシーの作成
まずは、自動修復するための権限が必要になります。自動修復には裏でSSMが動きますのでSSMに付与する権限を作成します。
今回の場合は、セキュリティグループのルールを修正する権限になりますのでIAMポリシーとIAMロールを作成していきます。
AWSマネージメントコンソール > IAM > ポリシー > 「ポリシーの作成」をクリックします。
以下のJSONをIAMポリシーのエディタに貼り付けます。
※インバウンドルールを削除する権限を付与します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "ec2:RevokeSecurityGroupIngress",
            "Resource": "*"
        }
    ]
}

ポリシー名は適宜設定するとよいでしょう。
画像では「Revoke-SecurityGroup」としています。

入力後、他の設定はデフォルトのままにしておき、
最下段の「ポリシーの作成」をクリックし、IAMポリシーを作成します。

IAMロールの作成
次にIAMロールを作成します。前工程で作ったIAMポリシーを付与します。
IAM > ロール > 「ロールを作成」をクリックします。
信頼されたエンティティタイプ：「AWSのサービス」を選択
サービスまたはユースケース：「Systems Manager」を選択
ユースケース：「Systems Manager」を選択
「次へ」をクリック

許可するポリシーは、前工程で作成したIAMポリシー「Revoke-SecurityGroup」を選択します。「次へ」

ロール名を適宜入力します。
画像では「revoke-securitygroup-role」としてます。

他の設定はデフォルトのまま、最下段の「ロールを作成」をクリックするとIAMロールが出来上がります。
出来上がったIAMロールのARNをコピーしておきます。後の工程で使用します。

これで自動修復用の権限が出来上がりました。

修復アクションの設定
次に自動修復用の設定をしていきます。
AWSマネージメントコンソール > Config > ルールを選択。
ルール一覧画面から先程作成した「restricted-ssh」を選択し、
「アクション」 >  「修復の管理」をクリックします。
ここから自動修復の設定をしていきます。

修復方法を選択：自動修復を選択
修復アクション：AWS-DisablePublicAccessForSecurityGroupを選択

リソースIDパラメータ：GroupIdを選択
パラメータ欄のAutomationAssumeRole：先程コピーしたIAMロールのARNを貼り付けます。

この設定によりセキュリティグループのパラメータをGroupIdで受け取ることになります。実行ロールとして、先程作成したIAMロールを利用する形になります。
最下段の「変更を保存」をクリックします。
これで自動修復の設定が完了しました。セキュリティグループでSSHが全開放されている場合、自動削除が実行されるはずです。次の工程で動作を確認していきます。

自動修復動作確認

動作確認のためのセキュリティグループを作成します。
セキュリティグループ名は適宜入力します。インバウンドルールにSSH全開放のルールと比較のためにHTTPの全開放ルールも作成してみます。

Configの内容を確認します。
Config > ルール >「restricted-ssh」をクリック。
最下段の対象範囲内のリソースを確認します。少し待つと下記画像のように「アクションが正常に実行されました」というステータスに変わります。
修復機能が正常に動いたようですね。

セキュリティグループの中身を確認してみましょう。
HTTPの全開放ルールは残っていますが、SSH全開放ルールは存在していません。削除されていることが分かります。自動修復機能が利いていますね。

ちなみにCloudTrailのログにも削除された記録が出力されます。
イベント名 > RevokeSecurityGroupIngressという名前で出力されますので、
興味のある方は確認してみるとよいでしょう。
自動修復機能の確認は以上となります。

まとめ

Config ルールを使用することで、AWSリソースのルール違反を監視・検出することができるようになります。これにより、コンプライアンスの向上やセキュリティの強化、ベストプラクティスの遵守などを実現することができるようになります。効果的に利用したいものですね。

関連

参考

AWS Config ルールでのリソースの評価 - AWS Config