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

Slide 1

Slide 1 text

AWS Foundational Technical Review と向き合って得られたもの @AWS Startup Community Conference 2022 © VALUES, Inc. Template: https://template-parks.com/

Slide 2

Slide 2 text

このセッションには以下の情報があります／ありません ◯ FTR通過のための参考情報 ➢ 体験談 ➢ 対応しなければいけないこと ➢ 得られるメリット ✕ 各AWSサービス単位の詳細な技術情報注）2021.8に受診したFTRの体験に基づいています。現在は内容が異なる場合があります。

Slide 3

Slide 3 text

厚地暁 (あつちあきら） from ○ マーケティングとITの会社 ○ 2009～14期目 ○ エンジニアは14人/122人 ○ 文系卒、2001新卒でSIer、2012現職 ○ 執行役員CTO ○ 2歳6歳娘の父 ○ ドラムをたたく（ほぼジャズ）

Slide 4

Slide 4 text

9月にトロントの ESOMAR Congress に出ます（世界最大級のマーケティングリサーチカンファレンス）

Slide 5

Slide 5 text

https://www.valuesccg.com/dockpit/ ○ 「競合も、業界も、トレンドもわかる、マーケターのためのリサーチエンジン」 ○ 約250万ユーザのWeb行動データ + ビッグデータ処理技術 + 分析技術 + 可視化技術 ○ 約350社のご契約（有料） ○ Free版もあります ○ スタートアップ向け限定プランも予定

Slide 6

Slide 6 text

AWS Foundational Technical Review （以下FTR）とは

Slide 7

Slide 7 text

FTRとは https://aws.amazon.com/jp/partners/foundational-technical-review/ ○ APNソフトウェアパスでの評価 ○ 要はベスプラ追求チェック機構 ○ セルフチェック＋対面レビュー ○ セキュリティ・信頼性・ガバナンスに重点 ○ ごほうびがたくさん

Slide 8

Slide 8 text

FTR通過のごほうび ○ チェック＆改善による品質向上 ○ 認定ソフトウェア (AWS Qualiﬁed Software) ○ ファンディング ➢ マーケティングデベロップメントファンド(MDF) ➢ ほかにも注）ファンド可否や適用額はいろいろなパラメータがあるようなのでくわしくはAPN担当者の方にご相談ください

Slide 9

Slide 9 text

興味わいた？

Slide 10

Slide 10 text

レビューにむけて

Slide 11

Slide 11 text

レビューに至る経緯 ○ 2020年に折角テクノロジーパートナーになったのにリセットされて悔しい ○ ちょうど社内でもAWS最適化の取り組み ○ 主力サービスとして純粋に品質あげたい ○ パートナーシナジーほしい（前述）

Slide 12

Slide 12 text

○ お世辞にもモダンとはいえない ○ 典型的な継ぎ足しシステム ➢ 2011年～ ➢ EC2多用 ➢ シングルAWSアカウント ○ SWでなんとかしちゃう風潮 ○ さすがにこのままではマズイと感じるタイミング既存システムアーキテクチャ

Slide 13

Slide 13 text

いざ、レビュー（当時のすすめかた） ○ セルフチェック (Well-Architectedツール) ○ ウォークスルー（事前レビュー的な） ○ FTR申込み ➢ チェック結果や構成図等を送付 ○ レビュー！ ➢ Amazon Chime、日本語、複数人可 ➢ 約50項目、90分程度

Slide 14

Slide 14 text

ぼっこぼこ（泣）

Slide 15

Slide 15 text

ここからが本当のたたかい ○ こうなることは折り込み済み ➢ セルフチェックで把握 ➢ 諸事情で実施を急ぐ必要があった ○ 指摘の改善には6ヶ月の猶予 ➢ 半年かけてつぶしていくたたかい

Slide 16

Slide 16 text

レビューの中身と改善

Slide 17

Slide 17 text

FTR Requirements ○ 英語翻訳なので解釈が難しい場合も ○ ツールのFTR Lensと完全一致ではない ○ 抽象度／具体度や規模感も大小さまざま ○ 難しさの性質が分かれる ➢ 具体的なものは実装上の難易度 ➢ 抽象的なものは相応の論拠が必要

Slide 18

Slide 18 text

こういうライトなものもありますの例 ○ ルートユーザーのメールアドレスを含むアカウントの連絡先情報を、会社が所有するメールアドレスと電話番号に設定すべし。 ➢ 元からそうだし、変えるにしてもあまりシステム影響ない ○ 機密データを送信するときは、暗号化付きのプロトコルのみを使用すべし。 ➢ さすがに普通に構築していればそうなるのでは（まして機密データ）

Slide 19

Slide 19 text

こういうヘビーなものもありますの例 ○ 災害復旧の実装をテストして、実装を検証すべし。DRへのフェイルオーバーをテストして、RTOとRPO（目標復旧時点）が定期的におよびメジャーアップデート後に満たされていることを確認すべし。 ➢ AZ障害等を想定したDRテストを実施 ➢ 事前検証レベルはやることが多いが、RTO/RPOの確認をするにはほぼ本番どおりの環境が必要

Slide 20

Slide 20 text

意外とこういうものは無い／薄い（当時） ○ 機能要件側のアーキテクチャ自体の妥当性、効率性 ➢ EC2ならべて力技な感じでもそれ自体は問題ない ➢ 総じて「統制されているか」は問われる ○ セキュリティチェックシートの類にありがちなもの ➢ FW、ウィルス対策、攻撃対策 ➢ （MFA、パスワードポリシーはある） ○ 性能関連 ○ コスト関連

Slide 21

Slide 21 text

改善したこと

Slide 22

Slide 22 text

通過のための主な実装改善点 ○ AWS Org設定、マストなアカウント分割 ➢ 監査ログ保存 ○ S3, RDSの暗号化 ○ システム用途アクセスキーの撤廃 ○ 認証情報のSecretsManager移行 ○ DRテスト環境構築とテスト実施

Slide 23

Slide 23 text

並行して行ったもの ○ ベスプラにそったアカウント分割 ➢ ControlTower 等での統合管理 ➢ 個人サンドボックス環境 ○ SSO (Googleアカウント->AWS) ○ SessionManager移行

Slide 24

Slide 24 text

それぞれの詳細対応してメリット得られたポイント

Slide 25

Slide 25 text

改善）アカウント分割何でも入ってる闇アカウント ○ CloudTrailのログ切り出しはFTRでもマスト ○ その他ベスプラに沿って構築、ControlTower、AWS Conﬁg等で統合管理 ○ 強権限かつ最小権限で管理がシンプルに。クオータ抵触の回避 ○ サンドボックス環境の提供で一気に検証ハードルを低下 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

Slide 26

Slide 26 text

改善）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

Slide 27

Slide 27 text

改善）S3, RDS暗号化 ○ 設定から「暗号化を有効」。キーは問わない。 ○ RDSは運用中に変えるのはかなり厳しい（厳しかった） ○ S3はデフォルトだけでなく、既存の中身について別途対応 ○ S3はデフォルト（のデフォルト）無効、RDSはデフォルト有効

Slide 28

Slide 28 text

改善）システム用途アクセスキーの撤廃 ○ アクセスキーを使ってはならないわけではないが、「ローテーション」が必要とされる ➢ 事実上システム用途では使えない ○ すべてロールへ ○ CloudTrailのログを見ては、利用箇所をつぶしていく。。。 ○ 万が一の漏洩、に対して強固に

Slide 29

Slide 29 text

改善）SessionManager移行 ○ SessionManagerの利用自体はマストではないが、「適切なログの取得と管理」を実現する上で望ましい。 ○ ログ管理、SSO連携（合わせてMFA）、VPN+bastionからの脱却 ○ 初学者への導入コストも激減 VPN bastion servers servers Session Manager Terminal Browser

Slide 30

Slide 30 text

改善）認証情報のSecretsManager移行 ○ 各サービスの認証情報をコードに含めない／専用サービスを用いる ➢ コードからの除外は問題無いが、設定ファイル系が厳しい ○ 地味に手こずったのがTomcat -> MySQLの認証情報 ➢ コネクションプールを使うために、通常は設定ファイルに直接記載 ➢ 結局専用のDataSourceFactoryを作成 ■ あまり触れてこなかったこのあたりの動作原理を理解する機会に ○ こちらも万が一の漏洩、に対して強固に

Slide 31

Slide 31 text

改善）DRテスト環境構築とテスト実施 ○ 「RTO, RPOを満たすことを確認できるテスト」 ➢ 単にAZ障害のノード切り替え検証ではなく、総合的なテストが必要 ○ CloudFormationで疑似環境を再現 ➢ 定期的にやる必要があるため ➢ 復旧時間の検証が目的だと、RDS等のデータサイズも重要 ➢ 実際のテストよりも環境構築に何倍もかかった ○ 実際確認できた安心感＋いつでもテストできる安心感

Slide 32

Slide 32 text

たたかいの末、、、通過！（泣）

Slide 33

Slide 33 text

得られたもの

Slide 34

Slide 34 text

得られたもの ○ 改善によって得られた品質・運用改善 ➢ 前述の　のとおり ○ 箔 ➢ バッジ（ちょっとシンプル、、） ○ MDF（FTR以外にも条件はある） ○ 「向き合って」得られた知見・自信

Slide 35

Slide 35 text

MDF (Marketing Development Funds) ○ （弊社の場合） ○ AWSパートナー向け資金提供プログラムのひとつ ➢ FTR通過 → APNソフトウェアパスにて「認定ソフトウェア」となり適用 ○ 「マーケティングコンシェルジュサービス」 ➢ 対象ソフトウェアの販促活動についての相談／支援窓口 ○ マーケティングプランを作成→その活動を行うための資金援助 ➢ 割とあらゆる販促活動で適用可能

Slide 36

Slide 36 text

「向き合って」得られた知見・自信 ○ システムはどのような品質上の観点を持つべきか、そしてその観点のためにどのような具体解があるのかを理解できた ➢ 永続的な鍵文字列を持たないためにロールやSecretsManagerがある ➢ 適切な権限付与のためにアカウントを分割する ➢ SessionManagerは適切なログ管理のためでもある ○ これらは、単にFTRを「通過する」だけでなく、きちんと「向き合う」ことで得られる ➢ 単に手法のみに従うだけではもったいない ➢ AWSに限らず汎用的なベストプラクティスとして昇華できる ○ （結果、担当者はその後SAP、SCSを取得できました）

Slide 37

Slide 37 text

これからの方につたえたいこと ○ 通過だけを目指さず、きちんと向き合ってほしい ➢ FTRと、だけでなく、自分たちのシステムと、でもあります。 ➢ このような儀式をきっかけに使わないとなかなか取り組めない内容。 ○ といいつつ、とりあえず受けておくとよいです ➢ FTR設問項目自体にも改善の余地は多いように思います。 ➢ 受診が増えるとフィードバックも増え、FTR自体の品質があがると思います。 ○ あとから対応がしんどいやつに気をつけましょう ➢ S3/RDSの暗号化、ロール徹底、ログの統制（CloudTrail, SessionManager等） ➢ DRテスト対策。環境構築をCloudFormationでやるとよさげ。 ○ 「必要条件」であり「十分条件」ではない ➢ 問われない観点も多い

Slide 38

Slide 38 text

Thanks!! @accakr https://www.facebook.com/acclegato Contact me! https://meety.net/matches/IkJnFtIEsMjG もちろんエンジニアさん募集中

Slide 39

Slide 39 text

FAQ ○ いちばんしんどかった項目は ➢ 作業量的にはDR対応、サービス影響はRDS暗号化、難易度的にはSecretsManager対応 ○ 今後の課題は ➢ 機能要件側のベスプラ化、EC2脱却、インシデント管理の効率化、などなど、、、 ○ 反省点 ➢ 観点はSIerの知見を使えるが、実装はAWSのお作法にきちんと従うべき。力技するな。