AWS Foundational Technical Review と向き合って得られたもの

https://aws-startup-community.connpass.com/event/247548/
登壇資料

Transcript

1. AWS Foundational Technical Review と向き合って得られたもの @AWS Startup Community Conference 2022 © VALUES, Inc. Template: https://template-parks.com/
2. このセッションには以下の情報があります／ありません ◯ FTR通過のための参考情報 ➢ 体験談 ➢ 対応しなければいけないこと ➢ 得られるメリット ✕ 各AWSサービス単位の詳細な技術情報 注）2021.8に受診したFTRの体験に基づいています。 現在は内容が異なる場合があります。
3. 厚地 暁 (あつち あきら） from ◦ マーケティングとITの会社 ◦ 2009～14期目 ◦ エンジニアは14人/122人 ◦ 文系卒、2001新卒でSIer、2012現職 ◦ 執行役員CTO ◦ 2歳6歳娘の父 ◦ ドラムをたたく（ほぼジャズ）
4. 9月にトロントの ESOMAR Congress に出ます （世界最大級のマーケティングリサーチカンファレンス）
5. https://www.valuesccg.com/dockpit/ ◦ 「競合も、業界も、トレンドもわかる、 マーケターのためのリサーチエンジン」 ◦ 約250万ユーザのWeb行動データ + ビッグデータ処理技術 + 分析技術 + 可視化技術 ◦ 約350社のご契約（有料） ◦ Free版もあります ◦ スタートアップ向け限定プランも予定
6. AWS Foundational Technical Review （以下FTR）とは
7. FTRとは https://aws.amazon.com/jp/partners/foundational-technical-review/ ◦ APNソフトウェアパスでの評価 ◦ 要はベスプラ追求チェック機構 ◦ セルフチェック＋対面レビュー ◦ セキュリティ・信頼性・ガバナンスに重点 ◦ ごほうびがたくさん
8. FTR通過のごほうび ◦ チェック＆改善による品質向上 ◦ 認定ソフトウェア (AWS Qualified Software) ◦ ファンディング ➢ マーケティングデベロップメントファンド(MDF) ➢ ほかにも 注）ファンド可否や適用額はいろいろなパラメータがあるようなので くわしくはAPN担当者の方にご相談ください
9. 興味わいた？
10. レビューにむけて
11. レビューに至る経緯 ◦ 2020年に折角テクノロジーパートナーに なったのにリセットされて悔しい ◦ ちょうど社内でもAWS最適化の取り組み ◦ 主力サービスとして純粋に品質あげたい ◦ パートナーシナジーほしい（前述）
12. ◦ お世辞にもモダンとはいえない ◦ 典型的な継ぎ足しシステム ➢ 2011年～ ➢ EC2多用 ➢ シングルAWSアカウント ◦ SWでなんとかしちゃう風潮 ◦ さすがにこのままではマズイと感 じるタイミング 既存システムアーキテクチャ
13. いざ、レビュー（当時のすすめかた） ◦ セルフチェック (Well-Architectedツール) ◦ ウォークスルー（事前レビュー的な） ◦ FTR申込み ➢ チェック結果や構成図等を送付 ◦ レビュー！ ➢ Amazon Chime、日本語、複数人可 ➢ 約50項目、90分程度
14. ぼっこぼこ（泣）
15. ここからが本当のたたかい ◦ こうなることは折り込み済み ➢ セルフチェックで把握 ➢ 諸事情で実施を急ぐ必要があった ◦ 指摘の改善には6ヶ月の猶予 ➢ 半年かけてつぶしていくたたかい
16. レビューの中身と改善
17. FTR Requirements ◦ 英語翻訳なので解釈が難しい場合も ◦ ツールのFTR Lensと完全一致ではない ◦ 抽象度／具体度や規模感も大小さまざま ◦ 難しさの性質が分かれる ➢ 具体的なものは実装上の難易度 ➢ 抽象的なものは相応の論拠が必要
18. こういうライトなものもありますの例 ◦ ルートユーザーのメールアドレスを含むアカウントの連絡先情報 を、会社が所有するメールアドレスと電話番号に設定すべし。 ➢ 元からそうだし、変えるにしてもあまりシステム影響ない ◦ 機密データを送信するときは、暗号化付きのプロトコルのみを使用 すべし。 ➢ さすがに普通に構築していればそうなるのでは （まして機密データ）
19. こういうヘビーなものもありますの例 ◦ 災害復旧の実装をテストして、実装を検証すべし。DRへのフェイル オーバーをテストして、RTOとRPO（目標復旧時点）が定期的にお よびメジャーアップデート後に満たされていることを確認すべし。 ➢ AZ障害等を想定したDRテストを実施 ➢ 事前検証レベルはやることが多いが、RTO/RPOの確認をするに はほぼ本番どおりの環境が必要
20. 意外とこういうものは無い／薄い（当時） ◦ 機能要件側のアーキテクチャ自体の妥当性、効率性 ➢ EC2ならべて力技な感じでもそれ自体は問題ない ➢ 総じて「統制されているか」は問われる ◦ セキュリティチェックシートの類にありがちなもの ➢ FW、ウィルス対策、攻撃対策 ➢ （MFA、パスワードポリシーはある） ◦ 性能関連 ◦ コスト関連
21. 改善したこと
22. 通過のための主な実装改善点 ◦ AWS Org設定、マストなアカウント分割 ➢ 監査ログ保存 ◦ S3, RDSの暗号化 ◦ システム用途アクセスキーの撤廃 ◦ 認証情報のSecretsManager移行 ◦ DRテスト環境構築とテスト実施
23. 並行して行ったもの ◦ ベスプラにそったアカウント分割 ➢ ControlTower 等での統合管理 ➢ 個人サンドボックス環境 ◦ SSO (Googleアカウント->AWS) ◦ SessionManager移行
24. それぞれの詳細 対応してメリット得られたポイント
25. 改善）アカウント分割 何でも入ってる 闇アカウント ◦ CloudTrailのログ切り出しはFTRでもマスト ◦ その他ベスプラに沿って構築、ControlTower、AWS Config等で統合管理 ◦ 強権限かつ最小権限で管理がシンプルに。クオータ抵触の回避 ◦ サンドボックス環境の提供で一気に検証ハードルを低下 Audit LogArchive orgadmin user-a user-b user-c dev-a dev-b dev-c prd-a prd-b prd-c core sandbox develop product AWS Organizations
26. 改善）IAM Identity Center適用（旧AWS SSO） ◦ アカウント単位でのIAM認証→SSOで一括管理+Google認証と連携 ➢ Googleアカウントで強制MFAのためそこに寄せる ◦ もうとにかく快適 ◦ できるだけデフォルトの許可セットでコントロールできるように IAM User IAM Role IAM Identity Center user-a dev-b prd-b orgadmin console console user-a dev-b prd-b orgadmin
27. 改善）S3, RDS暗号化 ◦ 設定から「暗号化を有効」。キーは問わない。 ◦ RDSは運用中に変えるのはかなり厳しい（厳しかった） ◦ S3はデフォルトだけでなく、既存の中身について別途対応 ◦ S3はデフォルト（のデフォルト）無効、RDSはデフォルト有効
28. 改善）システム用途アクセスキーの撤廃 ◦ アクセスキーを使ってはならないわけではないが、 「ローテーション」が必要とされる ➢ 事実上システム用途では使えない ◦ すべてロールへ ◦ CloudTrailのログを見ては、利用箇所をつぶしていく。。。 ◦ 万が一の漏洩、に対して強固に
29. 改善）SessionManager移行 ◦ SessionManagerの利用自体はマストではないが、「適切なログの取得と管 理」を実現する上で望ましい。 ◦ ログ管理、SSO連携（合わせてMFA）、VPN+bastionからの脱却 ◦ 初学者への導入コストも激減 VPN bastion servers servers Session Manager Terminal Browser
30. 改善）認証情報のSecretsManager移行 ◦ 各サービスの認証情報をコードに含めない／専用サービスを用いる ➢ コードからの除外は問題無いが、設定ファイル系が厳しい ◦ 地味に手こずったのがTomcat -> MySQLの認証情報 ➢ コネクションプールを使うために、通常は設定ファイルに直接記載 ➢ 結局専用のDataSourceFactoryを作成 ▪ あまり触れてこなかったこのあたりの動作原理を理解する機会に ◦ こちらも万が一の漏洩、に対して強固に
31. 改善）DRテスト環境構築とテスト実施 ◦ 「RTO, RPOを満たすことを確認できるテスト」 ➢ 単にAZ障害のノード切り替え検証ではなく、総合的なテストが必要 ◦ CloudFormationで疑似環境を再現 ➢ 定期的にやる必要があるため ➢ 復旧時間の検証が目的だと、RDS等のデータサイズも重要 ➢ 実際のテストよりも環境構築に何倍もかかった ◦ 実際確認できた安心感＋いつでもテストできる安心感
32. たたかいの末、、、 通過！（泣）
33. 得られたもの
34. 得られたもの ◦ 改善によって得られた品質・運用改善 ➢ 前述の 　 のとおり ◦ 箔 ➢ バッジ（ちょっとシンプル、、） ◦ MDF（FTR以外にも条件はある） ◦ 「向き合って」得られた知見・自信
35. MDF (Marketing Development Funds) ◦ （弊社の場合） ◦ AWSパートナー向け資金提供プログラムのひとつ ➢ FTR通過 → APNソフトウェアパスにて「認定ソフトウェア」となり適用 ◦ 「マーケティングコンシェルジュサービス」 ➢ 対象ソフトウェアの販促活動についての相談／支援窓口 ◦ マーケティングプランを作成→その活動を行うための資金援助 ➢ 割とあらゆる販促活動で適用可能
36. 「向き合って」得られた知見・自信 ◦ システムはどのような品質上の観点を持つべきか、そしてその観点のため にどのような具体解があるのかを理解できた ➢ 永続的な鍵文字列を持たないためにロールやSecretsManagerがある ➢ 適切な権限付与のためにアカウントを分割する ➢ SessionManagerは適切なログ管理のためでもある ◦ これらは、単にFTRを「通過する」だけでなく、きちんと「向き合う」こと で得られる ➢ 単に手法のみに従うだけではもったいない ➢ AWSに限らず汎用的なベストプラクティスとして昇華できる ◦ （結果、担当者はその後SAP、SCSを取得できました）
37. これからの方につたえたいこと ◦ 通過だけを目指さず、きちんと向き合ってほしい ➢ FTRと、だけでなく、自分たちのシステムと、でもあります。 ➢ このような儀式をきっかけに使わないとなかなか取り組めない内容。 ◦ といいつつ、とりあえず受けておくとよいです ➢ FTR設問項目自体にも改善の余地は多いように思います。 ➢ 受診が増えるとフィードバックも増え、FTR自体の品質があがると思います。 ◦ あとから対応がしんどいやつに気をつけましょう ➢ S3/RDSの暗号化、ロール徹底、ログの統制（CloudTrail, SessionManager等） ➢ DRテスト対策。環境構築をCloudFormationでやるとよさげ。 ◦ 「必要条件」であり「十分条件」ではない ➢ 問われない観点も多い
38. Thanks!! @accakr https://www.facebook.com/acclegato Contact me! https://meety.net/matches/IkJnFtIEsMjG もちろん エンジニアさん 募集中
39. FAQ ◦ いちばんしんどかった項目は ➢ 作業量的にはDR対応、サービス影響はRDS暗号化、難易度的にはSecretsManager対応 ◦ 今後の課題は ➢ 機能要件側のベスプラ化、EC2脱却、インシデント管理の効率化、などなど、、、 ◦ 反省点 ➢ 観点はSIerの知見を使えるが、実装はAWSのお作法にきちんと従うべき。力技するな。