insightwatchのセキュリティチェックでオールグリーンを目指す（その1: CISベンチマーク IAM設定編）
オペレーション部 江口です。
当社が提供するサービスであるinsightwatchでは、自分のAWS環境についてCISベンチマークやAWSセキュリティチェックリスト、IAMベストプラクティスといった規準でチェックを行うことができます。 チェックを全てパスすれば、非常に堅牢にAWSを運用することができますが、しかしながら全てのチェックを全てパスし、オールグリーンにするのはなかなか難しいようです。
実際のユーザ様への参考の意味も兼ねて、身をもって自分の個人検証用のAWS環境でオールグリーンを目指し、その過程をブログで公開していこうと思います。
今回の記事では、CISベンチマーク(CIS Amazon Web Service Foundations Banchmark v1.2)の「1 Identity and Access Management」の指摘事項をすべて解消するところまで紹介します。
参考情報
「insightwatchとはなんぞや？」や「どうチェックするのか？」「CISベンチマークって何？」という方のためにいかに各種情報へのリンクを挙げておきます。ご参考くださいませ。
- insightwatch:
- insightwatchへの新規の登録やチェックの実行の仕方の解説：
- CISベンチマークについての解説：
最初のチェック結果
さて、とりあえず私の個人検証環境をinsightwatchでチェックしてみた最初の結果は下記の通りです。
注意12個、重要45個の指摘があります。結構てんこ盛りですね・・・ 入社して1ヶ月にも満たないまだ私の検証環境にはそれほどAWSリソースはないのですが。
このうち「CIS 1. Identity and Access Management」のチェック結果の詳細は以下の通りです。
ちなみに「マネージド」という項目がありますが、これは当社サービス「クラスメソッドメンバーズ」をご契約されている際、当社で管理している項目について表示されます。rootアカウントなどを当社で管理しているので、それらについてはユーザ様は対応をする必要がありません。私のアカウントもクラスメソッドメンバーズで管理されていますので、対象項目は同様に「マネージド」となっています。
それでは個々の項目を潰していきます。
各IAMパスワードポリシー(CIS 1.5 - 1.11)
1.5から1.11はいずれもIAMパスワードポリシーのチェック項目となります。まとめると「大文字・小文字・記号・数字必須で最低14文字、パスワードの再利用を24世代まで禁止、パスワード有効期限が90日以内」というポリシーとなります。
GUIであればIAMコンソール -「アカウント設定」から各項目を変更します。 またAWS CLIで各ポリシーを一気に流し込むこともできます。
aws iam update-account-password-policy \
--minimum-password-length 14 \
--max-password-age 90 \
--password-reuse-prevention 24 \
--require-symbols \
--require-numbers \
--require-uppercase-characters \
--require-lowercase-characters \
--allow-users-to-change-password
一番後ろのパラメータ「--allow-users-to-change-password」は、ユーザにパスワード変更の許可を求めるというオプションで、上記の要件には上がっていないのですが、IAMベストプラクティスに含まれているのでついでに設定しています。 CLIで設定した場合の確認のコマンドは下記です。
aws iam get-account-password-policy
GUIでは下記のようになっていればOKです。
私の環境では1.9-1.11が引っかかっていましたが、上記対応ですべてクリアです。
CIS 1.16 IAMポリシーがグループまたはロールにのみ適用されていること
この要件はIAMポリシーにユーザに直接アタッチしていると引っかかります。ユーザがそれぞれポリシーをアタッチしていると管理上複雑となるので、必要なポリシーを持つグループを作り、そのグループにユーザをアタッチしたほうが良い、というわけです。
私の環境の場合、CodeCommit用に作ったgituserというユーザに直接ポリシーをアタッチしていました。推奨に従って、同じポリシーを持つ新しいグループを作ってそれをアタッチする形に変更しました。
手順は下記の通りです。
- IAMコンソール -「ユーザ」で、一覧から各ユーザをクリック。「アクセス権限」タブのポリシー情報で、直接アタッチ済みのポリシーを確認
- IAMコンソール -「グループ」で新しくグループを作成し、1で確認したポリシーをアタッチ
- 再びユーザの設定画面に戻り、「アクセス権限」タブでユーザに直接アタッチしていたポリシーをデタッチ（ポリシー情報の右の「x」をクリック）
- 「グループ」タブに移動し、「ユーザをグループに追加」を押して、新規に作成したグループをユーザにアタッチ
CIS 1.19 EC2でのAWSリソースへのAPIアクセスはIAMインスタンスロールを利用していること
これはIAMロールが設定されていないEC2が存在すると引っかかります。 AWSリソースにEC2でアクセスする場合、IAMロールを使わない場合はアクセスキーを使用する事になるので、それは止めてIAMロールを使った方が安全ですよ、ということですね。 確かに1台IAMロールを設定していないEC2インスタンスがあったのですが、これは実際他のAWSリソースにアクセスしないEC2で別にアクセスキーも使っていないので問題にはならないのでは・・・と思わないではないです。
実際はこれはCISベンチマークではLevel2、すなわち「環境により設定が必要」と分類されるもので、チェックの結果も「重要」ではなく「注意」となっています。 ですので必ずしも対応する必要があるわけではありません。 ただ、今回はオールグリーンにするのが目的なので、一応IAMロールを設定しておくことにします。
とはいえ他のAWSリソースには接続しないインスタンスなので、どこかしらにアクセスを許可するロールをアタッチするのは避けたいところです。 ということで、全てのアクセスを拒否するポリシー「AWS Deny All」をアタッチしたIAMロールを作成し、これを設定しました。Deny Allとか設定すると通信もできなくならないかとちょっと心配しましたが、SSH接続に支障はありませんでした。
CIS 1.21 不要なアクセスキーの発行を避ける
使っていないアクセスキーがあれば削除したほうがいい、ということです。無効化しただけでは駄目なようで（試した）、削除しないと引っかかるようです。 確認してみると前掲のユーザ「gituser」で利用していないアクセスキーが確かにあったので削除対応しました。
CIS 1.22 制限なしのアクセス許可を指定したIAMポリシーを利用しない
フルに全てのリソースにアクセスできるAdmin権限（マネージドポリシーで言うとAdministratorAccess）を使わない、ということですね。 当社では、各自の検証環境へは一旦社内AWS基幹のアカウントでログイン、その後スイッチロールして検証環境に入るルールで、この際のロールにAdministratorAccessポリシーがアタッチされています。
※スイッチロール/クロスアカウントアクセスについては以下の記事をご参照ください:
このロールを編集する必要がありますが、どのようにするべきか。
考えた結果、既存のロールはIAM権限を最低限とした「普段の検証用に使うロール」とし、それに加えて「IAMを管理するロール」を別途用意することにしました。IAMの管理が必要な時だけ、このIAM管理用ロールにスイッチロールする想定です。
まず普段検証で利用するユーザですが、以下の記事を参考にしてIAM以外の操作が可能なPowerUserポリシーと、IAMロールをリソースに設定する（パスする）ポリシーをアタッチすることにしました。リソースにIAMロールを設定するケースは多いため、これがないと検証は若干面倒になります。
IAM管理用ロールにはポリシーとしてIAMFullAccessを割り当てました
まとめると以下のような設定です。 「IAMPassRoleAccess」は前掲の記事を参考に設定したポリシーです。
| ロール | 割り当てポリシー |
|---|---|
| 普段の検証用 | PowerUser, IAMPassRoleAccess |
| IAM管理用 | IAMFullAccess |
なお、今回はIAM管理にはIAMFullAccessを割り当てましたが、理想としては下記記事にあるように、IAM管理もユーザ等を作成する「マスターロール」と割り当てを行える「マネージャロール」に分けるのが良いと思います。
注：このロールの分割もかつては上記の記事にある通りCISベンチマークに含まれていたのですが、バージョンがv1.1からv1.2に上がった際に削除されています。とはいえセキュリティをより強化できるので、紹介させていただきました。
ここまでの結果
ここまでの対処で、当初注意1個・重要6個の指摘があった「CIS 1. Identity and Access Management」の結果はマネージドの項目以外すべて「正常」となりました。
全体での成績は次の通りです。
最初のチェック結果が注意12個・重要45個であったのに比べて注意11個(-1)・重要31個(-14)となりました。対処した項目よりも指摘数が減っていますが、これは対処によりIAMベストプラクティスなど他のセキュリティチェックの項目も結果的にクリアしたためです。
とはいえまだまだ指摘事項は山積みですので、引き続き対処して行きたいと思います。
そしてこの記事でinsightwatchのセキュリティチェックに興味を持った方は、ぜひともこのサービスに登録してみてください（無料で使えます！）。そしてご自身の環境でもオールグリーンを目指してみてください！
