概要
久しぶりに長いタイトルを書いてしまいましたが、当エントリーではタイトル通りTrend Micro Cloud One Conformity(以後C1C)のReport機能を活用して既存AWS環境をチェックし、AWS Well Architectedのベストプラクティス準拠を目指していく 1つの考え方 についてご紹介します。
※当エントリーには、執筆者個人の見解を含みます。情報の取捨選択は自己責任でお願いします。
- 概要
- AWS Well-Architected Tool について
- C1C レポート機能について
- AWS Well Architected Framework に特化したレポート
- (重要) 出力されたレポートをレビューする際の心得え
- まとめ
- 関連エントリー
AWS Well-Architected Tool について
Well-Architected レビューで役立つ無料ツールとして「AWS Well-Architected Tool 」が用意されており、 AWSマネジメントコンソールから利用可能です。
こちらを使ってセルフで実施可能となっており、もし支援が必要な場合には、AWSパートナーやAWSのソリューションアーキテクトに依頼してレビューを実施するという形になっています。
個人的に考える当ツールでのレビュー対応における弱点
一言でいうと「対応する人への依存が大きい」というのが弱点であると考えています。
※執筆者 個人の見解ですのでご注意ください
AWS Well-Architected Toolのレンズ(質問集) SEC 7の実画面 (言語設定:日本語)を見てみます。
元が英語の内容の翻訳だからというのもあるのかもしれませんが、例えAWS Well-Architected Framework ホワイトペーパーを熟読した有識者の方でも初めて利用する場合は、質問文章の解釈からスタートする事がほとんどになると思われます。
AWS Well Architected Frameworkは世界中の様々な用途の環境をカバーできるものとして入念に考えられているものです。
当然カバー範囲が膨大な分、必然的に曖昧というか「うちの環境だと何が該当するのだろう？」と迷ってしまうような質問も多くなりがちです。
当然、その質問文章でレビューの対応をする人のITリテラシー、AWSに関する知識、当該環境の熟知度 等の差でも結果が大きく変わる場合がある事でしょう。
それが問題というか、組織としてツールを上手く活用するための課題であると考えます。
弱点を補う為のCSPM
それを補う為に活用できるツールの1つとして、Cloud Security Posture Management (CSPM)製品のC1Cが考えられます。
様々な関係者が構築/維持管理しているパブリッククラウド環境では、どのようなリソースがどのような設定で稼働しているか全て把握する事は困難ですが、機械的に複数のパブリッククラウド環境を全体スキャンして横断的にリソース単位でのチェックおよび結果の可視化が可能となります。
今現在、存在するリソースに対しての設定がチェックされ、リスクが評価され、改善に必要な対応手順を示してくれるC1Cはまさに上で記載した、「うちの環境だと何が該当するのだろう？」 という疑問解決を支援するツールになり得ます。
AWS Well Architected Frameworkでも一回限りではなく定期的にチェックを行って、継続的に改善していく事が推奨されていますので、デフォルトで1h周期でbotがチェックを行ってくれるC1Cは継続的に役に立ちます。
ただし、C1Cを導入して対応を進めるからといって Well-Architected レビューが一切不要となるといった事ではないのでその点はご注意ください。
しかし、日頃からC1Cでリスクを可視化して改善の取り組みを行っているチームのAWS環境であれば、仮に突然Well-Architected レビューを受けた場合でも、良い結果が出るであろう事に違いありません。
C1C レポート機能について
ざっくり、C1C管理コンソールで描画されているリスクの情報をpdf , csv 形式でレポートとして出力する機能です。
ルール単位のグルーピング、リソース単位のグルーピング、各種フレームワーク単位のグルーピングが可能で、出力したい項目を細かく指定可能で、Emailでの送付と定期実行の機能も備えます。
オフィシャルのカタログから抜粋ですが、以下のような業界ベストプラクティスに準拠しているか チェックされた内容のレポーティングが可能です。
SOC2、ISO 27001、NIST、CIS、GDPR、PCI DSS、GDPR、HIPAA、AWS およびAzure Well-Architected Framework、CIS Microsoft Azure Foundations Security Benchmarkなど
その他詳細については以下オフィシャルサイトを参照ください www.cloudconformity.com
AWS Well Architected Framework に特化したレポート
レポート出力設定画面とその設定
以下、レポート出力設定画面となります。
デフォルトでは、選択可能なフレームワークも全てチェックが入っていますが、AWS Well Architected Framework のレビュー特化の場合にはこのように選択を絞ります。(必要に応じて、表示するリスクレベルは調整してください)
指定フレームワークの質問に対応するチェック結果が表示
すると、画面下に AWS Well Architected Frameworkのレンズ(質問集)とそれに該当する実リソースのチェック結果 が表示されます。
こちらが、C1Cを評価してきて私が一番感動を覚えた画面でもあります。
皆さんは如何でしょうか？
上の画面で確認できる範囲だと OPS11とOPS3は 0 となっていますが、こちらはAWSリソース云々の内容ではなく、C1Cのチェックでは計れないような質問項目となります。
このように、AWS Well-Architected Toolの質問を全てC1Cで網羅できる訳ではないという点も合わせてご理解ください。
カウントの意味
カウントのカラムに表示されている内容は以下の通りです。
「FAILURE : 3」 と出ている内容は、3つのAWSリソースがチェックに失敗し ベストプラクティスに逸脱している 可能性がある 事を示しています。
※ FAILURE = 悪と捉えないようご注意ください。
管理者として意識して、必要な場合対応すべき項目が FAILUREであると理解ください。
| 項目 | 詳細 |
|---|---|
| SUCCESS | チェックに成功 (ベストプラクティス準拠) |
| FAILURE | チェックに失敗 (ベストプラクティス逸脱の可能性あり) |
| SUPPRESSED | ユーザーにて手動で抑制(ミュート相当) |
| NOT SCORED | AWS APIの権限がなく評価不可(AWS Organization の Service Control Policy 等で制御がされている環境の場合等に発生) |
質問項目の意味の確認
セキュリティの質問で IDカラムの値が SEC7の内容を確認していきます。
[More info]を押下すると、AWSオフィシャルの対象項目の詳細頁へとジャンプできます。
こちらが最初に例として記載した AWS Well Architected Tool のレンズの SEC7 の質問と一致します。 C1CのUIが英語なので、こちらも英語で掲載します。
(参考) AWS Well Architected Tool の SEC7画面 (英語)
質問項目の展開
左の[vマーク]を押下すると、質問に対応するチェック項目のルール一覧が展開されます。 そして、更にそのルールの[+]を押下すると、実際に存在するAWSリソースに対するチェック結果が表示されます。
Link to Resource にあるリンクを押下すると、AWSマネジメントコンソールで当該リソースへとすぐにアクセスが可能です。
Resolve (解決)する場合
もし、チェックされたリソースを確認し、設定に問題がある事が判明した場合は [Resolve...] を押下するとルールに関する詳細と対応すべき内容が纏まったTrend Micro社のサイトへとジャンプ出来ます。
AWSマネジメントコンソール(GUI)での手順と、AWS CLI での手順が掲載されているので好みの方を選択出来るという点も有り難いポイントです。
今回の例だと、S3バケットがパブリック公開設定で読み取り可能な状態となっている事を検知した内容となります。 管理者が意図せず、誤って公開設定をしてしまっていたとしたら手順を参考にAWS実環境にて設定を見直します。
当然、設定を見直す前に公開設定を実際に行った方やら組織に対するヒアリングが次のアクションになる場合もあるかと思います。
Suppress (抑止)する場合
上の例の続きですが、もしそのS3バケットはWebコンテンツとして公開しておりパブリック公開設定がされていて問題がない場合は理由を記載し Suppress をしていく運用が良いと思われます。
リソース単位のチェック結果右側の [Suppress] を押下します。
以下画面が表示され Noteの枠にフリーフォーマットで情報を残せます。
今回の例では Suppress とする理由(S3バケットの用途)を記載しました。画面の通り日本語の入力も可能です。
組織によっては、当項目記載する際の社内フォーマットを定めるのも良いかもしれません。 例えばSuppressする理由だけでなく、実施者やら日付やら社内の承認に関するメタ情報 を加える等です。
ちなみにいつ誰が Suppress のオペレーションを実施したかについては、C1Cへの設定変更アクティビティとして情報が残りますのでご安心ください。
「Suppressする = AWS環境に対して何も実施しない」ので意味が薄いのでは？と感じられる方もいらっしゃるかもしれませんが、管理者として、リスクは勿論リソースの存在すら把握出来ていない状態と、把握したうえでSuppressする理由を書ける状態では雲泥の差があると考えます。
必要に応じてレポート出力
紹介してきた画面は実際に対応を進める為の内容でしたが、そのままの見た目近い形で pdfファイルとしてレポートの出力が可能です。
[] Include Individual check in PDF report にチェックを入れると、全てのルールのタブが開いたような詳細まで出力できます。 ただし大量な情報となるので、1200項目までという成約があります。利用する場合は、必要に応じてレポートする内容を絞る事も検討してください。(例: Securityの柱の項目のみとする、リスクレベルHigh以上とする 等）
PDFレポートのサンプル
CSVレポートのサンプル
スケジュール実行も可能なので、例えば月に一度とか3ヶ月に一度とか定期出力し、必要に応じてチームでレビューし必要な対応を進める事でAWS Well Architectedのベストプラクティスへの準拠に役立てたり、静止点として保存する観点でも役に立つ場合があるかもしれません。
(重要) 出力されたレポートをレビューする際の心得え
AWS Well Architected Frameworkでは「レビュープロセス」の項目でレビューをどのような心得えでどのように進めるべきかが定められています。
C1Cのレポートをレビューする際にも、こちらの考えを踏襲する事を推奨します。
記載内容から引用ですが
アーキテクチャの評価は非難せずに掘り下げることができる一貫した方法で実施される必要があります。これは何日もかけずに数時間で終わる軽いプロセスである必要があります。話し合いであり、監査ではありません。
という文章が最初にあります。
こちらの特に以下2点が大変重要になってきますので、レビューのMTG参加者全員が理解した上での開催するよう心掛けてください。
- 非難せず、すなわち誰も責めるような事をしてはいけないという事
- 監査ではなく、前向きな話し合いであるという事
過去に参加したAWS主催の Well-Architected Bootcamp でも、レビューのミーティングの際には「おやつ」を持ち寄って和やかな雰囲気で開催する事をオススメしますと教わりました。(これは冗談ではなく)
対面でMTGする機会の減ったご時世ですが、リモートでもそういった工夫やら配慮は大切したいところです。
まとめ
C1Cを活用してAWS Well Architectedのベストプラクティス準拠を目指していく1つの考え方についてご紹介しました。
AWSからは、Well-Architected レビューについて、設計の初期段階で最初のレビューを実施し、その後の本番運用開始前に再度レビューを実施することが推奨されています。
それを実施出来ていない既存AWS環境は勿論、これから実施していく新規AWS環境でも AWS Well Architectedのベストプラクティス準拠に向けた対応でC1Cは役に立つであろう事が伝われば幸いです。
C1Cのオフィシャルサイトのトップ画面に「自信を持ってクラウドに構築する」といったキャッチコピーのような文言があるのですが、実際に製品を評価をしてみて私は割としっくりきました。
