はじめに
AWSは俊敏にリソースを調達できたりし、AWS社がある程度のセキュリティも担保してくれる一方でたとえばIaaSであれば、責任共有モデル的に、ユーザデータなどOS以上のレイヤーはユーザ自身の責任でセキュリティを担保しなければなりません。
設定ミス一つでデータのリークなど大事件につながることもありえます。
今回は、普段使用しているAWSアカウントにConformityというツールを導入して採点してみようと思います。
導入方法
以下のサイトのFree Trialでアカウントを作成します。作成すると14日間無料で使用できます。
https://www.cloudconformity.com/help/
次に登録時に入力したメールアドレスおよびパスワードを使用し、「Sign in」します。
サインインして、次にAWSアカウントをConformityに登録し、アカウント連携をします。
連携方法は非常に簡単で、画面左ペインの「Add an account」を選択し、「AWS Account」を選択します。
ちなみに、AzureのSubscriptionも追加できるようですが、今回はAWSアカウントを追加します。
初期のセットアップには、自動セットアップ（Automated setup）と手動セットアップ（Manual setup）がありますが、自動セットアップでは用意されたCloudFormationで数分でセットアップできます。
CloudFormationだと何を設定されているかわからないという不安な方は手動セットアップで手順を見ながら、設定内容をよく確認して、設定を行えばよいでしょう。
以上、初期設定が完了となります。
特に管理サーバを用意する必要もないため、サインインから導入までたぶん5分もあればできてしまうかもです。
AWSアカウントをチェックする
Conformityを導入し、しばらくすると以下のような結果が表示されます。
AWS Well-Architectedフレームワークを意識し、AWS Well-Architectureの5本柱に沿って結果表示されています。
パーセンテージが低いほど結果が良くないということになりますが、Operation Excellenceが明らかに低かったです。でも検証で使ったりしている環境なのでこの環境においては運用上の優秀性（Operational Excenllence）は二の次かもしれません。（笑）
次にセキュリティにフォーカスし、見てみましょう。「Improve...」を押すと検知した結果の一覧を確認することができます。EC2からCloudWatchの設定までいろいろと指摘されてしまいました。以下のスクリーンショットは検知内容の一部にすぎません。
この中で「EC2 Instance Not in Public Subnet」というルールにひっかかりましたが、Public SubnetにEc2に配置してはいけなかったのですか？なぜでしょう？早速「Resolve...」を押して理由を確認してみましょう。そうすると以下の内容が表示されます。
英語か。。。。Google翻訳を使いましょう（笑）
なるほど。。。要するに閉鎖されたネットワークにEC2を配置し、パブリックネットワークの後ろにプライベートネットワークを用意し、EC2はそのプライベートネットワークに展開すべきということですね。
さあ、いかがでしょうか。特にAWSへ移行中のユーザであれば、こういったツールがあると非常に便利かもしれません。特にテスト段階で展開してみて、設定不備やベストプラクティスに沿ってない構成を早期に見つけることが大事ですね、商用環境に展開してしまうとなかなか構成が変えられませんので、早めに設定不備を見つけることが非常に重要だと私は思います。
ちなみに、複数のAWSアカウントを登録できるようなので、たぶん想定されるユースケースは社内のセキュリティチームか何かで一元管理して、全社のAWSアカウントを管理したりとか、他社向けに監視サービスを提供したりとかでしょうか。
また、検知した内容を指定のユーザにメールで検知した内容と解決策をメールなどで送ることができますので、これで監視センターの気分を味わうことができますね（笑）
また、全リージョンのステータスの可視化機能もありどこのリージョンが危険なことになっているかが一目瞭然です。
さらに過去の状況を可視化できます。改善状況や、改悪状況（笑）も確認できます。
チェックに使われているルールはなんと！600個以上も存在しています。
コンプライアンス準拠確認
個人のテストでは使うことはあまりないかもしれませんが、商用環境でAWS環境を使用する際に、コンプライアンス準拠か否かが気になることも多いと思います。
Conformityを使用すれば、コンプライアンス違反になりうる設定不備をレポート化できます。
対応するコンプライアンスは以下のものがあります。
HIPAA
NIST Cybersecurity Framework
PCIDSS
GDPR
などなど
定期的に通知を受信する
Conformityでは定期的に外部のアプリケーションに通知を送ることもできるようです。
これでいちいちログインをしなくても検知状況を受け取ることができます。
試しにSlackに連携してみると、以下の画面のように検知内容を受信することができます。
さらに、Rule：XXXXXをクリックするとKBに飛ぶので、検知理由を確認することができます。
View resourceをクリックすればAWSコンソールに入り、検知された対象が表示されます。この例の場合は、アクセスキーが45日以上そのまま放置されていたため、アクセスキーのローテーションを行うことで対処できます。
ここまで読んでいただいて、Conformityを使ってみたくなったのではないでしょうか？でも、Conformityを使うと余分なお金がかかるのではないかと心配されるかもしれませんが、Conformityを導入しても余分な費用はかからないそうです。
https://www.cloudconformity.com/frequently-asked-questions.html
まとめ
さて、いかがでしたでしょうか？
AWS勉強中の私でも、このツールを使いながら、設定不備を見つけられそうです。
これを使ってみて、感じたことですが、
１．Conformityの導入が簡単で、特に管理サーバを用意したりするといった手間もかかりません。
２．複数のアカウントを一元管理できます。
３．検知した内容はすべてKBでその理由などの説明があり、どう対処すべきかが分かりやすいです。
４．チェックに使われるルール数が非常に多いです。（言い換えるとチェックが厳しいということになります。）
５．DevOpsを意識した設計で、通知やレポート機能が充実しています。