あなたのAWSセキュリティ監査状況を採点〜CISベンチマークを読んでみた
西澤です。先日、CIS(Center for Internet Security)よりCIS AWS Foundation Benchmarkが発表されました。CISは、セキュリティの促進を目的とした米国の非営利団体で、専門家により精査されたセキュリティ基準を公開してくれています。今回、公開されたドキュメントを読み解くことで、AWSを利用する上で必要となるセキュリティ設定について理解を深めることができればと目を通してみることにしました。
CISベンチマークとは?
CISとは下記のような非営利団体です。
米国のNSA(National Security Agency/国家安全保障局)、DISA(Difense Informaton Systems Agency/国防情報システム局)、NIST(National Institute of Standards and Technology/米国立標準技術研究所)などの米国政府機関と、企業、学術機関などが協力して、インターネット・セキュリティ標準化に取り組む団体の名称。
CIS(Center for Internet Security) - マルチメディア/インターネット事典
このベンチマークを利用することで、ユーザは下記のようなメリットを享受することができます。
- removes guesswork for security professionals
- ベストプラクティスに従った適切なセキュリティ設定をガイドしてもらえる
- consistently evaluate the security of an AWS account
- 標準化されたシステム設定により、コストをかけずに、リスクを低減し、システム監査を行うことができる
- integrated into the security and audit ecosystem
- PCIDSSやFedRAMP等の各種セキュリティ監査エコシステムにも適用できる
以前、PCIDSSに準拠したセキュリティ標準を策定する際、CISベンチマークを叩き台として利用したことがあるのですが、このベンチマークの素晴らしいところは、基準が明確で、設定・確認方法が具体的に記載されていることです。それぞれのシステムの設定項目について、手順付きのチェックリストを確認していくだけで、定量的に採点することができるというのが素晴らしいと思います。
AWS CIS Foundations Benchmark
各項目については、下記分類が設けられていますので、参考にしてください。Level1でかつSocredなものは設定しておくことが推奨されると考えれば良いと思います。
- Level
- Level1: 設定が必須のもの
- Level2: 環境により設定が必要なもの
- Score
- Scored: 評価(Score)にて減点対象となる項目
- Unscored: 評価(Score)にて減点対象とはされないが設定が推奨される項目
それでは、早速各項目についてざっと目を通して行きましょう。
(2018年5月追記)以降の記載は、最新版である"CIS Amazon Web Services Foundations Benchmark v1.1.0"に合わせて更新しました。
1. IAM
IAMに関するチェック項目は以下の通りです。
- rootアカウントが利用されていないこと(Level1,Scored)
- コンソールログイン用のパスワードが設定されたIAMユーザにMFAが有効化されていること(Level1,Scored)
- 90日以上利用されていない認証情報は無効化されていること(Level1,Scored)
- アクセスキーが90日以内にローテーションされていること(Level1,Scored)
- パスワードポリシーが設定されていること
- 1文字以上の大文字(Level1,Scored)
- 1文字以上の小文字(Level1,Scored)
- 1文字以上の記号(Level1,Scored)
- 1文字以上の数字(Level1,Scored)
- 14文字以上のパスワード(Level1,Scored)
- パスワードの再利用禁止(Level1,Scored)
- 90日以内のパスワード有効期限(Level1,Scored)
- rootアカウントのアクセスキーが設定されていないこと(Level1,Scored)
- rootアカウントがMFAにより保護されていること(Level1,Scored)
- rootアカウントがハードウェアMFAにより保護されていること(Level2,Scored)
- 秘密の質問が設定されていること(Level1,NotScored)
- IAMポリシーがグループまたはロールにのみ適用されていること(Level1,Scored)
- 詳細な請求レポートを有効化していること(Level1,Scored)
- IAM管理者の権限を、"作成のみ"の担当者(IAMマスター)と"割り当てのみ"の担当者(IAMマネージャー)に分離していること(Level1,Scored)
- 契約者情報が最新化されており、特定の個人のみに紐付いていないこと(Level1,Scored)
- セキュリティ担当者の連絡先が登録されていること(Level1,Scored)
- EC2からのAWSリソースアクセスにIAMロールが利用されていること(Level2,NotScored)
- インシデント管理の為にAWSサポートへの権限が用意されていること(Level1,Scored)
- IAMユーザ作成時に不必要なアクセスキーが生成されていないこと(Level1,NotScored)
- フルコントロール(全リソースおよび全アクション)権限を持つポリシーが作成されていないこと(Level1,Scored)
14文字以上のパスワードはちょっと厳しいですかね。他は概ねIAMのベストプラクティスとして広く謳われているところかと思います。
2. Logging
ログ出力に関するチェック項目は以下の通りです。
- 全RegionでCloudTrailが有効であること(Level1,Scored)
- CloudTrailログファイルの検証が有効化されていること(Level2,Scored)
- CloudTrailログの格納バケットが公開設定となっていないこと(Level1,Scored)
- CloudTrailログがCloudWatch Logsに配信設定されていること(Level1,Scored)
- 全RegionでAWS Configが有効であること(Level1,Scored)
- CloudTrailログの格納バケットがログ有効化されていること(Level1,Scored)
- CloudTrailログがSSE-KMSで暗号化設定されていること(Level2,Scored)
- KMSマスタキーがローテーション設定されていること(Level2,Scored)
正直、急に敷居が上がった感じがあります。AWS Configの全Region設定等、ここまでやっているケースは少ないような気もしますが、監査要件が厳しいシステムではこれくらい厳格に監査ログ取得およびその管理を行う必要があるということがわかります。
3. Monitoring
監視に関するチェック項目は以下の通りです。
- 許可されていないAPIコールに対して、アラーム通知設定されていること(Level1,Scored)
- MFAなしでのAWSマネージメントコンソールログインに対して、アラーム通知設定されていること(Level1,Scored)
- rootアカウントの利用に対して、アラーム通知設定されていること(Level1,Scored)
- IAMポリシーの変更に対して、アラーム通知設定されていること(Level1,Scored)
- CloudTrail設定の変更に対して、アラーム通知設定されていること(Level1,Scored)
- AWSマネージメントコンソールのログイン失敗に対して、アラーム通知設定されていること(Level2,Scored)
- KMSマスターキーの無効化またはスケジュール削除に対して、アラーム通知設定されていること(Level2,Scored)
- S3バケットポリシー変更に対して、アラーム通知設定されていること(Level1,Scored)
- AWS Config設定の変更に対して、アラーム通知設定されていること(Level2,Scored)
- Security Group設定の変更に対して、アラーム通知設定されていること(Level2,Scored)
- Network ACL設定の変更に対して、アラーム通知設定されていること(Level2,Scored)
- Internet Gateway設定の変更に対して、アラーム通知設定されていること(Level1,Scored)
- Route Tabley設定の変更に対して、アラーム通知設定されていること(Level1,Scored)
- VPC設定(新規作成、削除やVPC Peering, Classi Link等)の変更に対して、アラーム通知設定されていること(Level1,Scored)
- SNS TopicのSubscriberに適切な連絡先が設定されていること(Level1,NotScored)
適切なシステム監査を行う為には、ログを取得するだけでなく、重要な変更操作に気付くことができる仕組みが求められていることがわかります。
4. Networking
ネットワークに関するチェック項目は以下の通りです。
- Security Groupにて、0.0.0.0/0からport 22(SSH)への接続が許可されていないこと(Level1,Scored)
- Security Groupにて、0.0.0.0/0からport 3389(RDP)への接続が許可されていないこと(Level1,Scored)
- 利用可能な全てのRegionにおいて、VPC Flow Logsが有効化されていること(Level2,Scored)
- Default Security Groupが全ての通信を許可していないこと(Level2,Scored)
- VPC Peering越しのルーティングは必要最低限に絞られていること(Level2,NotScored)
必要最低限の通信要件のみに通信先を絞ることができているかが重要であることがわかります。
その他のCISベンチマーク
CISでは、AWSだけでなく、より上位のOS(Amazon Linux, CentOS, RHEL, SUSE Linux, Ubuntu, AIX, Solaris, Windows Server等)や、DB(Oracle, DB2, MS SQL, MySQL)、MW(Apache, IIS)などの様々なレイヤでベンチマークが公開されています。あなたの構築・運用するシステムが適切なセキュリティ監査設定を携えているか、確認してみてはいかがでしょうか?
自動でCISベンチマークを計測する
最後にお使いのAWSアカウントに対するCISベンチマークの計測を自動で行えるinsightwatch(インサイトウォッチ)という無料のプロダクトをご紹介します。insightwatchはCISからプロダクト認定を受けており、最新のv1.2に対応しています。
URLは以下になります。「セキュリティチェックを始める」というボタンを押すとサインインの画面になります。
AWS環境のセキュリティ監査サービス インサイトウォッチ(insightwatch)by クラスメソッド
サインアップの手順やチェックするAWSアカウントの登録など手順は以下になります。簡単にできますのでぜひお試しください。
まとめ
全てにおいてこのベンチマークの通りに設定していなければ、セキュリティ上問題がある、ということは決してありません。CISベンチマークの情報そのものの更新が追いつかず、最新となっていない場合もありますし、システムの環境によってはその全ての設定を施すこと自体にあまり意味を成さないケースもあるはずです。このような網羅的なチェック項目に対して、対応できていない項目については、何故そうなっていないのか?、何故そうする必要が無いのか?、を説明できるようにしておくことが重要です。
何よりも、システム担当者がコンプライアンスやセキュリティの意識を強く持ち、このような基準を意識してシステムを運用していくことが最も重要なのではないかと思います。公式ドキュメントには、なぜそのような設定が必要で、どのような意図や基準に基づいて項目が用意されてあるのか、詳しく説明されていますので、詳しく目を通してみていただければと思います。