AWS Config Rules用のGitHubリポジトリが公開されました！

森永大志

2016.03.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Config芸人の森永です。

昨年2015年のre:Inventで発表された新サービス「AWS Config Rules」
AWSリソースの設定がルールに則っているかチェックするというサービスですが、少し困ったことがありました。

ルールには大きく2種類、AWSが作成・管理している「マネージドルール」と自分で作成する「カスタムルール」というものがあるのですが、「カスタムルール」は自分でLambdaを使って作成する必要がありました。

シェルスクリプトしか日常的に書かない私にはちょっと気が重かったりします。
（そこはちゃんとやれよ、というツッコミごもっともです。）

AWS Config Rules Repository

今回、AWS Config Rulesのルールを共有する場としてGitHubのリポジトリが公式に公開されました！
マネージド、カスタムの中間ぐらいの位置づけの、「人の作ったよさ気なルール」が選択肢として加わったということです。

また、GitHubなので、自分で作った素晴らしいルールを世界のみんなに公開することも可能です。

現在、公開されているルールは以下の通りです。

IAMの設定でパスワードポリシーが設定されているか
パスワードポリシーに正しい「パスワードの最小長」が設定されているか
パスワードポリシーに正しい「パスワードの有効期限」が設定されているか
パスワードポリシーに「少なくとも1つの大文字が必要」が設定されているか
パスワードポリシーに「少なくとも1つの小文字が必要」が設定されているか
パスワードポリシーに「少なくとも1つの数字が必要」が設定されているか
パスワードポリシーに「少なくとも1つの記号が必要」が設定されているか
パスワードポリシーに正しい「パスワードの再利用を禁止」が設定されているか
EC2インスタンスが正しいテナンシーに設定されているか（Shared,Dedicated,DedicatedHost）
全リージョンでCloudTrailが有効化されているか
IAMユーザのアクセスキーが一定期間内にローテートされているか
ルートアカウントのアクセスキーが無効化されているか
ルートアカウントのMFA認証が設定されているか
IAMユーザのMFA認証が設定されているか
全てのリージョンでCloudTrailのログバリデーションが有効化されているか
全てのリージョンでAWS Configが有効化されているか
全てのEC2インスタンスが指定されたインスタンスタイプになっているか
特定のリソースタイプ（EC2など）が指定された数を超えていないか

個人的には、ローテートを忘れやすい11番や全ユーザ管理が難しい14番なんかが非常に使い勝手がいいルールだなと思います。

ただ、今上げたルールはあくまでも現状あるルールなので、今後どんどん追加されていくでしょう！

試してみる

個人的に使ってみたい11番のルールで試してみます。
やり方はカスタムルールの設定方法と同様です。

現在、AWS Config Rulesが使用できるのはバージニアリージョンだけなので、そちらで検証します。（東京はよ！）

AWS_Config_Console

AWS Configのサービス画面から「Rules」→「Add rule」を選択します。

AWS_Config_Console 2

マネージドルールの選択画面が出ますが、人の作ったカスタムルールを使用するので、「Add custom rule」を選択します。

AWS_Config_Console 3

名前、説明をいい感じに決めます。（今回は元の名前と説明をまるっとコピペしました）
名前を決めたら、「Create AWS Lambda function」でLambda functionを作成していきます。

AWS_Config_Console 4

blueprint選択画面がありますが、毎度のごとくここはSkipします。

Lambda_Management_Console

次に、Lambda functionの名前、説明を入力します。
面倒なのでルールと同じものを使用しました。
言語については、カスタムルールによって違いますので適したものを選びましょう。
（今のところNode.jsが9割、Python1割くらいです。）

Lambda_Management_Console 2

GitHubで目的のカスタムルールのコードをコピーします。
ファイルをS3にアップロードして、、、というのでもいいのですが、1ファイルで完結しているのでコピペのほうが早いです。
「RAW」タンを押してから、Ctrl+a Ctrl+cでコピーすれば完璧です。

aws-config-rules_iam_access_key_rotation-triggered_js_at_master_·_awslabs_aws-config-rules

GitHubでコピーしてきたコードをLambdaの画面にペーストします。

Lambda_Management_Console 3

次に、Handlerの設定をします。
初期値はindex.handlerになっていると思いますが、コードの中のhoge.handlerを見つけ出し、その値を設定して下さい。
今回はexports.handlerとなっていました。

Lambda_Management_Console 4

次にIAM Roleの設定でLambdaに権限を与えてあげるのですが、ちょっとここが面倒です。
ルールに応じて必要な権限を設定して上げる必要があります。

コードを見ると、最初に

var config = new aws.ConfigService();
var iam = new aws.IAM();

とあることから、configとiamの権限を使用することが分かります。
configとiamで検索してみると、config.putEvaluationsとiam.listAccessKeysを使用していました。
これをポリシーに記載する際には、config:putEvaluationsとiam:listAccessKeysとなります（ピリオドではなく、コロン）のでご注意下さい。

これを調べたうえで「AWS Config role」を選択し、IAM Roleを作成します。

Lambda_Management_Console 5

「ポリシードキュメントを表示」を押すとどのようなポリシーを設定するかを確認できます。
この中にiam.listAccessKeysがないので、追加して上げる必要があります。
「編集」を押して、ポリシーを編集できるようにします。

IAM_Management_Console

元あったポリシーは残しつつ、以下のように設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::*/AWSLogs/*/Config/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "config:Put*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:listAccessKeys"
            ],
            "Resource": "*"
        }
    ]
}

iam.listAccessKeysの部分はお使いのルールに応じて変更して下さい。
（必要なポリシーもルールと一緒に記載されていると親切ですね。自分が作るときは心がけます。）

ポリシーの設定が終わったら「許可」して、Lambdaの設定画面に戻ります。
Advanced settingsですが、特にこだわりがなければこのままでいいです。
「Next」を押しちゃいましょう。

Lambda_Management_Console 6

設定をレビューして、問題なければ「Create function」を押します。

Lambda_Management_Console 7

こうなったら、Lambda functionの作成は成功です。
右上に表示される「ARN」の値をメモして、Config Rulesの設定画面に戻ります。

Lambda_Management_Console 8

「AWS Lambda function ARN」に作成したLambda functionのARNを貼り付けたらLambdaの設定は完了です。

AWS_Config_Console 5

次に、Triggerの設定に移ります。
「AWSリソースが変更された際に検査」をするか、「定期的に検査」をするかを選択できます。
公開されているルールのファイル名末尾がtriggeredとなっているものは「変更時に検査」で、periodicとなっているものは「定期的に検査」です。
今回はiam_access_key_rotation-triggered.jsというファイル名なので、IAMユーザが「変更時に検査」と設定します。

AWS_Config_Console 8

次はパラメータの設定です。
ルールによってはパラメータが必要な物があります。

こちらのページに必要なパラメータは記載されています。
今回はMaximumAccessKeyAgeというアクセスキーの有効期限のパラメータを設定します。
（が、上の一覧と実際のコードの中とパラメータ値が違う可能性がありますので、うまく行かなかったらコードを眺めてみてください。上の一覧にはMaximumAPIKeyAgeと書いてあったのでハマりました。。。）

AWS_Config_Console 6

以上で終了です。
「Save」を押してルールを作成しましょう。

ルール作成をすると「Evaluating...」という検査中の状態になります。

AWS_Config_Console 7

暫く待つとあらら、、、90日以上アクセスキーをローテートしていないアクセスキーがあるようです。

AWS_Config_Console 10

キーをローテートして、暫く待つと再度検査をしてComliantになりました！
ちなみに、キーをローテートする際に、昔のキーを削除せずにInactiveにするという事をすることが多いかと思いますが、現状はInactiveでも古いアクセスキーだとNGなようです。
（後でInactiveは検査しないようなプルリク送っておきます。）

AWS_Config_Console 11