こんにちは、IT業界7ヶ月の田所です。
皆様、AWSのWell-Architected Frameworkってご存知でしょうか？
もちろん知っていますか？さすがですね！
私は恥ずかしながらあまり知りませんでした。
ですので先日AWS公式のBootcampに参加してエッセンスを学んできました。
AWSは見たり触ったりしたことがあるけれど、Well-Architected Frameworkが何かと言われると説明に困る、、
今日はそんな方を対象にお話ししたいと思います。
ついでにアイレットなら経験が浅くても、こんな風にWell-Architected Frameworkを学ぶ機会があるよ！ということもお伝えしたいと思います。
1. アイレット向けWell-Architected Bootcamp
AWS Well-Architected Bootcampってなに？
AWS Well-Architected Bootcampとは、お題に沿ってWell-Architected Frameworkのレビューを行い議論する、AWSが主催するワークショップ形式のイベントです。
AWSパートナーネットワークに参加する企業のみが受講できるイベントです。
内容はProfessional（上級者）向けとなっており、1日がかりで行います。
こんな事業会社がこんなインフラ構成でこんな運用をしていて、、と設定が与えられ、その現状 (As-Is) と理想 (To-Be) をWell-Architected Frameworkと照らし合わせながら洗い出し、発表して話し合います。
平たく言うと、ベストプラクティスに沿っているか1日かけて議論しよう！の会です。
Frameworkには6つの柱、言わば6大テーマがあるため、全てチェックするとなるとなかなかに壮大です。
今回参加したイベント
そして今回参加したのがWell-Architected Mini Bootcamp for iretです。
Miniとある通りBootcampの縮小版で、個社向けに 6つの柱のうち1つにテーマを絞って行うワークショップです。
アイレットではWell-Architectedの推進を数年前から行なっており、社内で裾野を広げるためにこのMini bootcampをiret内でAWSさん講師の元に実施することとなりました。
上級者向けの1日がかりのトレーニングとなると参加できる人は限られてきますが、社内向けにテーマを絞って半日で行うワークショップであれば対象となる人数はグッと増えます。
今回はセキュリティの柱がテーマで、4時間のワークショップでした。
やったこと
1. お題の読み込み
以下について書かれた架空の設定を読み込んでいきます。
- 大まかな事業内容
- システム構成
- 運用方法
- 最近の事象、課題
文章量も多く、読んでもすんなり頭に入ってこない、、
ここで設定が整理されて頭に入って、問題点や解決策がそれとなく浮かぶようになったら立派なエンジニアなんだろうなあ、なんて思いつつできる範囲で消化していきます。
2. グループディスカッション
今回対象のFrameworkの柱はセキュリティでした。
その中にもたくさんの要素があるので、1グループあたり3つずつ割り振られます。
例えば、あなたのチームは設定に対して以下の3つを考えてください。のような感じです。
- SEC 1.ワークロードを安全に運用するには、どうすればよいですか?
- SEC 2.人とマシンの認証の管理はどのようにすればよいですか?
- SEC 3.人とマシンのアクセス許可はどのように管理すればよいでしょうか?
それぞれに対して現状 (As-Is) と理想 (To-Be) を話し合います。
例えば、本番、開発、テストを全て1つのアカウントで運用している場合、
SEC1のワークロードの安全な運用の観点ではアカウント使用のベストプラクティスに沿ってこのように考えることができます。
[As-Is] 重要度の異なるワークロードを単一のアカウントで行なっている。
[To-Be] 本番、開発、テスト環境を分離したマルチアカウントの構成にする。必要に応じて AWS OrganizationsやAWS Control Tower を導入する。
3. 発表
各チーム話し合った内容を発表していきます。
発表もさることながら、その質疑応答が大変盛り上がったのが印象的でした。
「ここはどう考えてそのサービスを選んだのですか？」のような発表内容に関する質問から、
「運用の現場ではこうなりがちで、、」とリアリティ溢れる提起があったり、
「AWSさんとしてはどう捉えていますか？」のように少し踏み込んだものもあり、
非常に活発な議論が行われました。
当日の様子は以下にまとめられています。
『Well Architected Mini Bootcamp for iret（セキュリティの柱）』の参加レポート
2. Well-Architected Frameworkとは？
今更ですが、Well-Architected Frameworkとはなんでしょう？
その概要や階層について簡単にご紹介します。
知っている方は読み飛ばしてください。
Well-Architected Framework
AWS公式ドキュメントによると、Well-Architected Framework は以下のように定義されています。
AWS Well-Architected フレームワークは、特定のアーキテクチャがクラウドのベストプラクティスと整合しているかどうかを理解するための一連の基本的な質問を文書化したものです。
つまり、この質問に全て答えられたらあなたのクラウドはバッチリ！なドキュメントです。
6つの柱
Well-Architected Frameworkは6つの柱と呼ばれる6大テーマを掲げています。
優秀なアーキテクチャは、以下6つの総合点が高いということです。
AWS Well-Architected フレームワークの柱
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- サステナビリティ
セキュリティの柱の項目
それぞれの柱の中にチェックすべき項目があります。
柱の中で着目すべき切り口や質問、といったところです。
セキュリティの柱の中には11個の項目があります。
多いですね。
- SEC 1.ワークロードを安全に運用するには、どうすればよいですか?
- SEC 2.人とマシンの認証の管理はどのようにすればよいですか?
・
・
・ - SEC 11.設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか?
ベストプラクティス
そして、それぞれの項目に紐づくベストプラクティスがあります。
“SEC 1.ワークロードを安全に運用するには、どうすればよいですか?” の中には8つのベストプラクティスがあります。
そろそろ頭がパンクしそうですね。
- SEC01-BP01 アカウントを使用してワークロードを分ける
- SEC01-BP02 セキュアアカウントのルートユーザーおよびプロパティ
・
・
・ - SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する
全体像
階層や数をまとめるとこうなります。
最大313のベストプラクティスと照らし合わせるとなると、Well-Archレビューが膨大な工数になるのは容易に想像できます。
また、このベストプラクティスを定めている方がいると思うと本当に頭が下がります。
2024年2月時点の集計です。
3. やさしいWell-Arch
つまりどういうこと？
と思ってしまった方。
私が身の丈に合ったWell-Archの例を説明してみようと思います。
良くない例
例えばこんな設定を想定してみます。
ちなみに今回のイベントの設問とは異なる設定です。
—– 以下設定 —–
ある企業は通販サイトを立ち上げました。
Route53で名前解決を行い、EC2でWebサイトのホストや注文の処理、商品や顧客情報の管理をしています。
また従業員は5人で、それぞれに権限が必要なためルートアカウントを使用しています。
アーキテクチャ
—– 設定ここまで —–
とんでもない設定ですね。
ツッコミどころがたくさん浮かんできましたか？
どこから手を付けたらいいのでしょうか。
どうやったら抜け漏れなくバランスの良い改善ができるでしょうか。
そもそも情報が少なすぎて何とも言えませんか？
現実に情報が全て揃っていることは少ないですよね。
これは実務ではヒアリングすべき事項ということになります。
（ということで今回は許してください）
やさしいWell-Arch
Well-Architected Frameworkのセキュリティの柱に則って、改善の例をふたつ挙げてみます。
1. ネットワークレイヤーを作成する
まずセキュリティの柱の中のこの項目に注目します。
何らかの形式のネットワーク接続があるワークロードは、インターネットでもプライベートネットワークでも、外部および内部ネットワークベースの脅威から保護するために、複数の防御レイヤーが必要です。
とのことです。
今回の例では複数のレイヤーに分かれていませんね。
そこで以下のベストプラクティスにならって、パブリックサブネットにあるデータベースの部分をもう少し堅牢にすることにします。
具体的には、プライベートサブネットにRDSを作成して、EC2からのアクセスに絞ります。
おなじみの構成に一歩近づきましたね。
2. 保管中に暗号化を適用する
こちらの項目も見てみます。
複数のコントロールを実装して保管中のデータを保護し、不正アクセスや不正処理のリスクを低減します。
以下のベストプラクティスを参考に、データの保護をしてみましょう。
具体的には、暗号化を有効にしたRDSを作成します。
改善の結果
初めの構成より、ネットワークリソースや保管中のデータの保護という観点で改善が見られたかと思います。
そしてまだまだツッコミどころが多いということも感じ取れるかと思います。
可用性は？アクセス制御は？脅威検出や監視の仕組みは？というかなんでルートアカウント使ってるの？
などなどたくさんあるかと思います。
313のベストプラクティスのうち、まだ311が未検討で残っているので当然ですね。
ただ、どんな切り口で改善を検討していくか、Well-Architected Frameworkの有用性の一端を垣間見ることができたのではないでしょうか。
4. イベントで感じたこと
そして今回のイベントに参加して実感したことを3つご紹介します。
餅は餅屋
理論的にはコンピュータの実機があれば、DNSやロードバランサー、Webサイトのホスト、データベースと全ての機能を実装できます。
しかしその知識や技術、運用やアップデートを全て自前で抱えるとなると、恐ろしい工数、コストがかかるのは想像に難くありません。
特に脆弱性対策のような日々更新がかかる性質のものを管理するとなると気が遠くなる、というかそこに労力をかけるべきなの？という気持ちになります。
ITの進化が常にそうであるように、巨人の肩を上手く活用していきたいものですね。
つまりマネージドサービスすごい。
常にトレードオフ
議論が深まれば深まる程、あれもできるこれもできるとアイディアで溢れてきます。
ACM, Secrets Manager, CloudTrail, CloudWatch, WAF, Config, GuardDuty, Shield Advanced, VPCフローログ, ELBログ, Route53リゾルバークエリログ, Backup, Organizations, Control Tower….
お金と人員に余裕があればやった方が良いとは思いますが、現実的な落とし所はサービスレベルやコストとの相談になるでしょう。
その企業や組織にとって、どこまで手を広げるのが適切なのかは意識しておく必要があると感じました。
最高のアーキテクチャより最適なアーキテクチャ。
草の根も大事
Well-Architected Frameworkと聞くと、いかに適切なアーキテクチャを組んで、いかに仕組みで対応するか、という世界だと思っていました。
実際間違ってはいないのですが、以下のようなベストプラクティスもあって少し意外に感じました。
人の手の介入をゼロにすることはできない以上、啓蒙活動を軽視する訳にはいかないのだと気付かされました。
インシデントを風化させない会を開く、カレンダーに自分の起こしたインシデント記念日(!?)を登録する、のような普段考えに及ばないアイディアを聞くこともできました。
5. おわりに
ここまでWell-Architected Frameworkのイベントや噛み砕いた内容についてお届けしてきました。
ひとつでも皆様の気付きになることがあったなら大変嬉しい限りです。
最後にアイレットの働く環境について強調したいと思います。
今回、IT業界7ヶ月の私がAWS公式のトレーニングでWell-Archを学んできました。
そうです、
アイレットなら経験年数に関わらず、Well-Archをはじめ、技術を学べる機会が揃っています！
まずアイレットはAWSプレミアティアサービスパートナーのため、Well-Architected Bootcampのような、AWSパートナーネットワーク限定のトレーニングを受けられます。
加えて、社内でWell-Archを浸透させる活動をしており、今回のWell-Architected Mini Bootcamp for iretのような、経験の浅いメンバーにも存分に学習機会が提供されています。
Well-Architected Bootcampは本来Professionalレベルの上級者向けですので、間口を広げてそのエッセンスを学べるMini Bootcampは私にとって大変ありがたかったです。
熟練の職人もいれば、ほかほかの新人もいる。
そんな中で様々なレベルに合わせて質の高いトレーニングを受けられる環境、魅力的だと思いませんか？
ということで、、
アイレットは一緒に働く仲間を募集しています！
最後までお読みいただきありがとうございました。
