潜んでいたリスクを可視化する
クラウド診断サービスで
安全かつ最適なクラウド運用が実現
はじめに
こんにちは。クラウド活用推進担当の植草です。
みなさん、 Well-Architected していますか？
わたしはこれまで社内やお客さまの様々なワークロードで AWS Well-Architected Framework (以下W-A) を用いたレビューを行ってきました。
AWS Well-Architected という名前は多くのお客さまやシステム担当者の間で認知されてきているなと思う一方で、うまく活用できていない所ががまだたくさんいらっしゃるなという印象です。
そこで、これまでわたしが携わってきたワークロードレビューの中から、よくある反応や、活用するために心掛けておくと良いことなどについて紹介したいと思います。
目次
ワークロードレビューのあるある
ワークロードレビューを行うなかで、よくあるバッドプラクティスをいくつか紹介します。
- 設計ドキュメントに "Well-Architected に準拠したシステムとすること" という記載があるけど、実際は Well-Architected なシステムになっていない
- ベストプラクティス (またはリスク) に対応するのかしないのかはっきりしない
- ベストプラクティス対応要否の根拠がドキュメントに明記されていない
- CSPM (AWS Security Hub など) で十分だと思っている
- お客さまの要件に無かったから対応していない
1. 設計ドキュメントに "Well-Architected に準拠したシステムとすること" という記載があるけど、実際は Well-Architected なシステムになっていない
設計ドキュメントには、そのワークロードが準拠すべきコンプライアンス基準を記載しますが、そこに "AWS Well-Architected に準拠～" という記述があるのをよく見かけます。
じゃあ、"このワークロードは W-A な設計となっているのか" というとそうでもなく、そもそもチームメンバーの中には W-A の存在自体を知らない方もいたりします。
"他システムの設計書をサンプルとして流用していてそこに W-A の記載があった" 、 "組織としてクラウドシステムのコンプライアンス基準が明確に定義されていないため、とりあえず W-A と記載している" といった声もありましたが、W-A は非常に有用なツールなのでこれはちょっともったいないです。
2. ベストプラクティス (またはリスク) に対応するのかしないのかはっきりしない
W-A は6つの柱、約60個の質問、約300個のベストプラクティスから構成されています。
これらすべての項目について対応しないとダメかというとそういうわけではなく、実際はワークロードの特性や、トレードオフを考慮しながら、対応するしないを決めていくことになります。
ただ、レビューをしていると、その場で対応するべきか悩んだり、人によって対応するしないの回答が異なることがあります。
例えば、セキュリティ、ガバナンス、信頼性、ユーザー体験、コストなどワークロードで考慮すべき観点は色々とありますが、どれを優先するのかを決めておかないと、リスク対応をやるのかやらないのかの判断がブレて一貫性の無い設計になってしまいます。
3. ベストプラクティス対応要否の根拠がドキュメントに明記されていない
レビューでヒアリングしていると色々と考えて設計されていることは分かるんですが、ドキュメントに明記されていないため、キーマンじゃないと分からないということが多々あります。
ワークロードによっては、キーマンが既に離任していてなぜそのような設計になっているか誰も分からないとなるケースもたまにあります。
せっかく色々と検討した結果決めているはずなのに、それを記録に残さないのは非常にもったいないし、設計根拠が分からないというのはそれ自体リスクでもあります。
4. CSPM (AWS Security Hub など) で十分だと思っている
クラウド設定の脆弱性の可視化・定期的なチェック手法としてCSPM (Cloud Security Posture Management) があります。
AWS でも Security Hub など CSPM 機能を持ったサービスがありますが、これを有効化して準拠状況をチェックしているので W-A の対応ができていると考えている人が一定数います。
CSPM はセキュリティリスクの検知に非常に有効な機能ですが、 W-A はセキュリティだけでなく運用・信頼性・コストなど多岐に渡り、システム的に抽出できるものは W-A の一部です。
また、 AWS では Trusted Advisor というサービスがあり、 W-A の一部をチェックできる機能がありますが、こちらもすべてをカバーしているわけではありません。
5. お客さまの要件に無かったから対応していない
お客さまがシステム開発を外部ベンダーに委託しているワークロードでたまにあるケースですが、W-A のベストプラクティスどおりに対応をしていない項目について、なぜ対応をしていないかを外部ベンダーの担当者に質問すると、 "要件に無かったから対応していない" と回答されることがあります。
たしかにお客さま要件に沿ったものを作るのが仕事ですが、そもそもお客さまが W-A を理解した上で要件を出してくることはまずありません。
Well-Architected な設計をするためには
W-A な設計とするための考慮点についていくつか紹介します。
- AWS 案件に参画するメンバーに、 W-A を知ってもらう
- 案件の様々なフェーズで W-A を活用する
- ワークロードの優先事項を決めておく
- ツールをうまく活用する
- 設計根拠をドキュメントに残す
1. AWS 案件に参画するメンバーに、 W-A を知ってもらう
AWS 案件に始めて携わる人は Cloud Practitioner や Solutions Architect - Associate などの認定の勉強から入ることがありますが、それに加えて、 W-A の概要や必要性を理解してもらうのが望ましいです。
2. 案件の様々なフェーズで W-A を活用する
W-A は案件の様々なフェーズで使うことができます。
要件定義フェーズでは、要件の網羅性・考慮漏れを確認するために使えます。設計フェーズでは設計時に W-A を基に対応要否を検討することができたり、設計したものが W-A に準拠しているかをチェックすることができます。リリース前のフェーズでは設計フェーズでの W-A レビューで出た項目の対応状況をチェックするのに使えます。運用フェーズではサービスリリース後のサービスアップデート対応などについて、定期的にチェックするのに使えます。
また、セキュリティの考え方で "シフトレフト" というもの (セキュリティ脆弱性は開発サイクルの早い段階で見つけたほうが対応にかかる工数が少なく済むよね) がありますが、 W-A も同様です。運用フェーズやリリース直前にリスクが分かったとしても、対応するためにアーキテクチャの見直しが必要となる場合は対応が難しいですが、設計フェーズで分かっていれば対応できたケースがあるかもしれません。なるべく早い段階から W-A を活用するのが望ましいです。
3. ワークロードの優先事項を決めておく
ワークロードではコンプライアンス基準などを定義しますが、合わせて、ワークロードの優先事項を決めてチームメンバーと共有することが望ましいです。
セキュリティ、信頼性、パフォーマンスなどすべてを考慮した対応ができれば最高ですが、実際はコストや様々なトレードオフが発生します。優先事項を決めておくことで、一貫した方針の設計をすることができます。
4. ツールをうまく活用する
AWS では、Trusted Advisor や AWS Security Hub といった、 W-A を補助するツールがあります。このツールで W-A すべてをチェックすることはできませんが、簡易的なチェックや、設計内容の裏付けを行うのに非常に有効です。構築時からこれらツールを有効化してチェックすることが望ましいです。
5. 設計根拠をドキュメントに残す
"なぜそのような設計としたのか" を必ずドキュメントに記載することが望ましいです。ドキュメント化することにより、チーム内外で認識を共有できるし、有識者離任時もドキュメントは残ります。
ドキュメントを作成していない、作成していても決定事項だけ残して根拠の記載が無いと "なんでこうしたんだっけ？" となるので、ドキュメントの形式は設計書や wiki などプロジェクトに合わせれば良いですが、必ず記載しましょう。
まとめ
W-A のあるあると、 AWS 設計の考慮点について紹介しました。
ぜひ皆さんも W-A を活用して、最適なシステム設計・カイゼンを行いましょう！