概要
原著者の許諾を得て翻訳・公開いたします。
- 英語記事: Free tools for auditing the security of an AWS account
- 公開日: 2017/05/30
- 著者: scott@summitroute.com
- サイト: Summit Route -- AWSセキュリティコンサルティングサービスです。
AWS関連情報は公開時点の原文記事に即しているため、日本語版・英語版でAWSの現状と異なる可能性があります。
本記事の内容に関する注意（必ずお読みください）
記事ではセキュリティチェックの手法として実際に攻撃してみて侵入テストを行うアプローチが紹介されていますが、AWSでは侵入テストについて明示的な制限があります。
第三者機関等にセキュリティチェックを依頼する際にはガイドラインを必ず確認し、AWS 脆弱性/侵入テストリクエストフォーム から事前に申請を行うようにしましょう。
※認可されない状態で侵入テストを行った場合、AWSのサービスに対する攻撃とみなされてペナルティや訴訟につながる可能性があります
なお、本記事で提示されている方法は侵入テストではなく既存設定の検証・チェックがメインなので、問題になることはないと思います。
無料で使えるAWSアカウント用セキュリティ監査ツールの紹介（翻訳）
AWS（Amazon Web Services）は一般にデフォルトでセキュアになっていますが、設定を誤る可能性があるうえ、初期設定で強制されていないベストプラクティスもいくつかあります。私はAWS Chicagoミートアップグループで、こうした点をチェックできるツールのいくつかについて触れました。本記事では、AWSアカウントに潜むセキュリティ問題の改善方法を見つけるのに役立つ、入手可能な既存のツールについて調べた結果をご紹介いたします。
ツールでチェックできるベストプラクティスの例としては「rootアカウントにMFA（Multi-Factor Authentication）が設定されているか」があります。ツールでチェックできる潜在的なセキュリティ問題の例としては「セキュリティグループの0.0.0.0/0がオープンか（外部からのネットワークトラフィックを無制限に許可していないかなど）」「S3バケットは外部から読み取り可能か」がありますが、その設定が正当かつ安全になされている可能性もありますので、自分の環境で検出される問題に偽陽性（false positive）が含まれる可能性をいつも念頭に置いておきましょう。監査ツールは、問題が潜む心配のある部分をリストアップするにとどまります。
ツールがAWSアカウント情報を収集する方法には次の3つがあります。
- AWS API呼び出しを多数実行して現在のアカウントの成り立ちに関する情報を分析する。
- CloudTrailログを監視して、問題のありそうな変更があったら警告を出力する。
- AWS Configログを使って現在のアカウントの成り立ちに関する情報を分析する。
本記事で扱う無料ツールは、すべて1.の「多数のAWS API呼び出し」に基いています。2のCloudTrailによる手法はAirbnbのStreamAlertで一部採り入れられています（例）が、無料ツールではあまり見かけません。3のAWS Configによる手法を使うツールは、無料のツールには見当たりません。
本記事のツールを使う場合、ツールをEC2インスタンスで実行する必要があり、かつEC2インスタンスに関連付けられるIAMロールにセキュリティ監査権限が必要です。
訳注: パラグラフを分割、再構成しました
別の方法（非推奨）
AWS CLIツールでAWSキーを設定すると、本記事のツールの多くが対応しているboto3ライブラリにそのAPIキーを与えられます。AWSキーを使うこの方法はおすすめできません。
flAWS challengeというサイトでLevel 6用キー（アカウントに対するツール実行権限を持つキー）が公開されているので簡単に触れておきますが、flAWSのアカウントには問題が多いうえ、本記事で扱うAWSサービスにはこの方法を使えません。
この方法は次のツールで利用可能です。
- AWS Trusted Advisor
- AWS Config
- Scout2
- Prowler
- Security Monkey
- Cloud Custodian
1. AWS Trusted Advisor
AWS Trusted Advisorは2014年7月にリリースされ、AWSアカウントに無料で付属します。https://console.aws.amazon.com/trustedadvisor/を開くだけで利用でき、セキュリティチェックのほかに、コスト最適化、パフォーマンス、フォールトトレランスもチェックできます。
全アカウントで利用できるチェックが3項目、月100ドルのAWSビジネスサポートプラン（リンク）を利用すると50項目以上のチェックも使えるようになります。
無料のチェック3種類
- 外部からの無制限アクセス(
0.0.0.0/0)を特定のポートで許可しているセキュリティグループ。ポート80（HTTP）や443（HTTPS）は問題ありませんが、ポート3306（MySQL）などの特定のポートがオープンになっている場合は赤色になります。ポート22（SSH）を含むその他のポートがオープンになっている場合は黄色になります。 - IAMユーザーを他にも作成したことがあるか（rootアカウントが複数ある可能性）。
- rootアカウントにMFAが設定されているか。
有料サポートで使えるチェックの一部
- S3バケットの権限に隙がないかのチェック。
- パスワードポリシーが設定されているかどうかのチェック。
- セキュリティグループ関連のチェック（RDSデータベースが露出しないためのSecurity Groupなど多数）。
- Route53で各
MXレコードをチェックし、対応するSPF値（メールスプーフィングを拒否する）がTXTレコードにあることを確認。 - CloudTrailがオンかどうかのチェック。
- ELBリスナーで使われるSSLポリシーが良いものかどうかのチェック。
- SSL証明書の期限切れが近いかどうかのチェック。
- IAMキーのローテーションが直近の90日以内に行われたかどうかのチェック。
- アクセスキーが露出していないかどうかのチェック。
最後のアクセスキー露出チェックは、問題を「アカウントの外」で探すという点で興味深いものです。Amazonによると「著名なコードリポジトリでアクセスキーが誰でも見られる状態になっていないか、およびAmazon Elastic Compute Cloud（Amazon EC2）でアクセスキーの悪用につながるような誤った使い方がされていないかをチェックする」とのことです。つまりAmazonは、GitHubをスキャンしてキーがないかどうかをチェックしたり、ビットコインマイニングに最適化した多数のEC2がある日突然全リージョンで動き出したりしないかどうかをチェックしたりしていることになります。
AWS Trusted Advisorの動作は妙に遅く、最初に何か表示されるまでしばらく待たされます。そこで特定の項目（0.0.0.0/0がオープンなセキュリティグループなど）を除外すると、画面更新までさらに5分ほどかかります。
このページをチェックしたくない場合は、console.aws.amazon.com/trustedadvisor/home#/preferencesで通知先を設定する必要があります。
以下のように設定すると毎週メールが届きます（便利というほどでもありませんが）。
同様に、自分のアカウントでhttps://console.aws.amazon.com/iam/の「セキュリティステータス」を表示すると、IAMベストプラクティスに沿っている項目には緑のチェックマークアイコンが、ベストプラクティスに沿っていない項目には三角の警告アイコンがそれぞれ表示されます。
他のツールと比べて、AWS Trusted Advisorにはどことなく「Amazonは対策を取っています」という姿勢を示す目的で作られたような官公庁的な匂いがあります。GitHubスキャンチェック（これは他のツールにはありません）の他にはAmazonのコスト負担はないのですから、全項目を無料にすればよいのにそうなっていないのも気になります。ともあれ、AWS Trusted Advisorは一部のチェックについては無料で利用でき、アカウントにビルトインされていて手間もかからないので、定期的に開いてチェックすべきでしょう。
2. AWS Config
AWS Configは2014年11月にAmazonによって導入されました（リンク）。AWS Configは次の2つの面で捉えられます。
- アカウント設定の全期間にわたる記録
- ルールエンジン: 項目を評価してSNS経由で警告を生成できる
AWS Configは、アカウントのあらゆる「設定項目」（EC2、S3バケット、Security Groupなど）の情報を全期間にわたって記録し、S3バケットに保存します。AWS Configは、CloudTrailログと、リソース情報取得用の多数のAWS API呼び出しの中間のようなツールです。最小限の全文検索機能を利用できます。たとえば特定のEC2インスタンスの情報などを検索するには、以下のようなクエリを使います。
aws configservice get-resource-config-history --resource-type "AWS::EC2::Instance" --resource-id "i-05bef8a081f307783"
クエリに--earlier-timeオプションを付けると、EC2インスタンスの設定が数日前にどうなっていたかを見ることもできます。このあたりはNetflixのEddaと似ています。EddaはAWS環境の情報を収集してMongoDBに保存し、REST APIにクエリをかけることができます。Eddaのクエリ機能はAWS Configよりも充実していますが、AWS Configはクリック操作で設定でき、データが揃えばいつでもS3バケット全体をgrepして必要な情報を取れるので、過去の特定の時期に環境がどのようになっていたかを把握するのであれば、CloudTrailログを読み解くよりも楽かもしれません。
情報の保存コストは、記録された1リソースあたり0.003ドルですが、ルール費用は1ルールあたり月2ドルと高めになっています。ルールの評価は、変更の検出で行うか、変更があるかどうかを定期的にテストするよう設定することで行います。
現時点ではAmazonの既存ルールが32個あり、独自ルールも作成できます。コミュニティが作成したルール（Amazon提供のルールの複製が大半）はここで一覧できます。ルールの追加は、以下のように簡単に行なえます。
問題が検出されると、SNS通知が起動します。
3. Scout2
iSEC Partners（現在はNCC Group傘下）のLoïc Simonが2012年にリリースしたScoutは、AWS環境を監査するツールです。2014年にリリースされた新バージョンはScout2という名前になりました。オープンソースのScout2はペネトレーションテスト（侵入テスト）によるワンタイム監査に特化しています。
Scout2コマンドを実行すると静的なWebディレクトリが作成され、ディレクトリ内のreport.htmlをブラウザで開けるようになります。Scout2の動作は少しバグっぽいので、何かをクリックして動かなくなったらページを再読み込みする必要がありますが、それでもUIは良いと思います。
クリックしてEC2ダッシュボードを開くと、そのサービスのissueの概要が表示されます。
赤になっている「SSH port open to all」を開くと、すべてのセキュリティグループで0.0.0.0/0がオープンになっていることがわかります。
セキュリティグループがどのインスタンスに適用されているかも確認できます。
4. Prowler
AlfrescoのToni de la Fuente（@ToniBlyx）が2016年9月にリリースしたprowlerは、CIS Amazon Web Services Foundations Benchmarkに記載されている項目をチェックするために開発されました。
このツールはレポートのissue表示のみに特化しています。コンソール上で（英語として）読み下せる単一のレポートを生成するのはProwlerだけです（アプリケーション形式のツールだと操作法を覚える必要があります）。
5. Security Monkey
Netflixが2014年にリリースしたSecurity Monkeyは、AWSとGoogle Cloud Platform（GCP）のどちらにも使える問題検出ツールです。Security Monkey全体をEC2としてデプロイすることを前提としており、バックエンドにPostgreSQLが必要です。複数のアカウントを繰り返しスキャンしてalertを生成でき、セキュリティチームはalert時にUI上でissueリストを一覧して問題点をチェックし、妥当性の承認や問題点の修正を行えます。
issueは次のように表示されます。
次の図では、選択したissueと妥当性承認（justification）の方法が示されています。複数のissueが1つのリソースでグループ化されるので、リソースごとにissueの妥当性を一括で承認することも一部のみ承認することもできます。
次の図ではリソースの詳細が示されており、検出された内容の理解に役立ちます。
Security Monkeyのコードについてはこちらをご覧ください。
6. Cloud Custodian
CapitalOneが2016年5月に発表したCloud Custodianは、他のツール同様に問題を検出するだけではなく、組織のルール遵守を実際に強制します。ルールによっては非常に厳格なものもあり、単にサービスを止めるだけでは遵守したとみなされません。含まれているポリシーのいくつかを例として示します。
- EC2インスタンスに暗号化EBSボリュームが1つもない場合は、そのインスタンスを即座にterminateする。
- EC2インスタンスにタグ付け（Environment、OwnerContactなど）されていない場合、4日以内にそのインスタンスをstopする。
- ELBでホワイトリスト付きのSSLポリシーが使われていない場合、ELBを削除する。
Cloud Custodianはタスクスケジューラで定期的に実行することも暗に期待されています。Cloud Custodianはポリシーを完全に満たすために、単独のSecurity Audit権限よりも強い権限を必要とします（EC2の停止なども行うため）。ルールは自分で作成するのが前提であるため、プロジェクトに含まれるルール例はそれほど多くありません。Cloud Custodianは、一部のインスタンスを夜間のみstopしてコストを削減するのにも使えます。
7. その他のツール
7-1. reddalert
Preziが2014年にリリースしたreddalertは、AWS APIを直接叩く他のツールと異なり、AWS Configの項で前述したNetflixのEddaを使っている点が特徴です。なお、reddalertはメンテナンスされなくなっているようです。
7-2. CloudSploit
CloudSploitは有料サービスですが、無料で使えるものが2つあります。1つはユーザーが自分のWebサイトで手動スキャンを実行する機能。もう1つはエンジンとルールがオープンソース化されて自分で動かせるようになったことです（プロジェクトのgithub.com/cloudsploit/scans）。「OK」を含んでいない行を検索してもよいでしょう。
まとめ
AWSのベストプラクティスをチェックするツールをご紹介いたしました。どのツールも、AWSアカウントに潜むすべての問題を検出するわけではありません（セキュリティパッチが当たっていない古いソフトウェアをEC2で動かしているなど）し、気にする必要もないようなissue（S3バケットが読み取り可能で公開されているが、そもそもWebサイトでコンテンツを一般公開している、など）にまでフラグを立てます。ツールを細かく調整し、環境に合わせてチェックを追加（場合によっては削除）するとよいでしょう。チェック項目によっては、API呼び出しがないために手動で実施しなければならないこともあります（アカウントにセキュリティ問題連絡先が設定されているかどうかなど）。
現時点では、1つですべてをまかなえるツールは存在しません。また、何をどうチェックするのかを丁寧に説明してくれるようなツールもありません。私は、この点を改良することを構想しています。
私から申し上げられる一般的なアドバイスとして、まずは自分のアカウントでAWS Trusted Advisorを開いてみてください。一度も開いたことがないのでしたら、今すぐ開いてください。AWS Trusted Advisorはセキュリティ問題を手軽にチェックでき、コスト削減・パフォーマンス・フォールトトレーランス関連の問題も指摘してくれるビルトインサービスです。
Scout2とprowlerは使いやすく、動作も軽快ですが、監査担当者による単発チェックに特化しています。Security Monkeyは、環境を監視する手段を求めているセキュリティチームにおすすめのツールです。その代わりインストールと設定が少々面倒です。AWSのサービスでやりたい方は、代わりにAWS Configをどうぞ。issueのalert生成のほかにルール遵守も強制したいのであれば、Cloud Custodianがよいでしょう。
最後になりましたが、AWS環境のセキュリティ強化を検討中の方は、ぜひscott@summitroute.comまでご連絡ください。