Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWS Foundational Technical Review と向き合って得られたもの
Search
Akira Atsuchi
August 26, 2022
Technology
2
1.1k
AWS Foundational Technical Review と向き合って得られたもの
https://aws-startup-community.connpass.com/event/247548/
登壇資料
Akira Atsuchi
August 26, 2022
Tweet
Share
Other Decks in Technology
See All in Technology
SA Night #2 FinatextのSA思想/SA Night #2 Finatext session
satoshiimai
1
150
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
18
7.1k
OpenID Connect for Identity Assurance の概要と翻訳版のご紹介 / 20250219-BizDay17-OIDC4IDA-Intro
oidfj
0
370
生成 AI プロダクトを育てる技術 〜データ品質向上による継続的な価値創出の実践〜
icoxfog417
PRO
5
1.8k
システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling
i125
1
250
利用終了したドメイン名の最強終活〜観測環境を育てて、分析・供養している件〜 / The Ultimate End-of-Life Preparation for Discontinued Domain Names
nttcom
2
310
AIエージェント元年
shukob
0
120
急成長する企業で作った、エンジニアが輝ける制度/ 20250214 Rinto Ikenoue
shift_evolve
3
1.9k
N=1から解き明かすAWS ソリューションアーキテクトの魅力
kiiwami
0
140
分解して理解する Aspire
nenonaninu
2
490
ユーザーストーリーマッピングから始めるアジャイルチームと並走するQA / Starting QA with User Story Mapping
katawara
0
260
レビューを増やしつつ 高評価維持するテクニック
tsuzuki817
1
830
Featured
See All Featured
Thoughts on Productivity
jonyablonski
69
4.5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
GitHub's CSS Performance
jonrohan
1030
460k
BBQ
matthewcrist
87
9.5k
Designing for humans not robots
tammielis
250
25k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
980
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Embracing the Ebb and Flow
colly
84
4.6k
Code Reviewing Like a Champion
maltzj
521
39k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Transcript
AWS Foundational Technical Review と向き合って得られたもの @AWS Startup Community Conference 2022
© VALUES, Inc. Template: https://template-parks.com/
このセッションには以下の情報があります/ありません ◯ FTR通過のための参考情報 ➢ 体験談 ➢ 対応しなければいけないこと ➢ 得られるメリット ✕
各AWSサービス単位の詳細な技術情報 注)2021.8に受診したFTRの体験に基づいています。 現在は内容が異なる場合があります。
厚地 暁 (あつち あきら) from ◦ マーケティングとITの会社 ◦ 2009~14期目 ◦
エンジニアは14人/122人 ◦ 文系卒、2001新卒でSIer、2012現職 ◦ 執行役員CTO ◦ 2歳6歳娘の父 ◦ ドラムをたたく(ほぼジャズ)
9月にトロントの ESOMAR Congress に出ます (世界最大級のマーケティングリサーチカンファレンス)
https://www.valuesccg.com/dockpit/ ◦ 「競合も、業界も、トレンドもわかる、 マーケターのためのリサーチエンジン」 ◦ 約250万ユーザのWeb行動データ + ビッグデータ処理技術 + 分析技術
+ 可視化技術 ◦ 約350社のご契約(有料) ◦ Free版もあります ◦ スタートアップ向け限定プランも予定
AWS Foundational Technical Review (以下FTR)とは
FTRとは https://aws.amazon.com/jp/partners/foundational-technical-review/ ◦ APNソフトウェアパスでの評価 ◦ 要はベスプラ追求チェック機構 ◦ セルフチェック+対面レビュー ◦ セキュリティ・信頼性・ガバナンスに重点
◦ ごほうびがたくさん
FTR通過のごほうび ◦ チェック&改善による品質向上 ◦ 認定ソフトウェア (AWS Qualified Software) ◦ ファンディング
➢ マーケティングデベロップメントファンド(MDF) ➢ ほかにも 注)ファンド可否や適用額はいろいろなパラメータがあるようなので くわしくはAPN担当者の方にご相談ください
興味わいた?
レビューにむけて
レビューに至る経緯 ◦ 2020年に折角テクノロジーパートナーに なったのにリセットされて悔しい ◦ ちょうど社内でもAWS最適化の取り組み ◦ 主力サービスとして純粋に品質あげたい ◦ パートナーシナジーほしい(前述)
◦ お世辞にもモダンとはいえない ◦ 典型的な継ぎ足しシステム ➢ 2011年~ ➢ EC2多用 ➢ シングルAWSアカウント
◦ SWでなんとかしちゃう風潮 ◦ さすがにこのままではマズイと感 じるタイミング 既存システムアーキテクチャ
いざ、レビュー(当時のすすめかた) ◦ セルフチェック (Well-Architectedツール) ◦ ウォークスルー(事前レビュー的な) ◦ FTR申込み ➢ チェック結果や構成図等を送付
◦ レビュー! ➢ Amazon Chime、日本語、複数人可 ➢ 約50項目、90分程度
ぼっこぼこ(泣)
ここからが本当のたたかい ◦ こうなることは折り込み済み ➢ セルフチェックで把握 ➢ 諸事情で実施を急ぐ必要があった ◦ 指摘の改善には6ヶ月の猶予 ➢
半年かけてつぶしていくたたかい
レビューの中身と改善
FTR Requirements ◦ 英語翻訳なので解釈が難しい場合も ◦ ツールのFTR Lensと完全一致ではない ◦ 抽象度/具体度や規模感も大小さまざま ◦
難しさの性質が分かれる ➢ 具体的なものは実装上の難易度 ➢ 抽象的なものは相応の論拠が必要
こういうライトなものもありますの例 ◦ ルートユーザーのメールアドレスを含むアカウントの連絡先情報 を、会社が所有するメールアドレスと電話番号に設定すべし。 ➢ 元からそうだし、変えるにしてもあまりシステム影響ない ◦ 機密データを送信するときは、暗号化付きのプロトコルのみを使用 すべし。 ➢
さすがに普通に構築していればそうなるのでは (まして機密データ)
こういうヘビーなものもありますの例 ◦ 災害復旧の実装をテストして、実装を検証すべし。DRへのフェイル オーバーをテストして、RTOとRPO(目標復旧時点)が定期的にお よびメジャーアップデート後に満たされていることを確認すべし。 ➢ AZ障害等を想定したDRテストを実施 ➢ 事前検証レベルはやることが多いが、RTO/RPOの確認をするに はほぼ本番どおりの環境が必要
意外とこういうものは無い/薄い(当時) ◦ 機能要件側のアーキテクチャ自体の妥当性、効率性 ➢ EC2ならべて力技な感じでもそれ自体は問題ない ➢ 総じて「統制されているか」は問われる ◦ セキュリティチェックシートの類にありがちなもの ➢
FW、ウィルス対策、攻撃対策 ➢ (MFA、パスワードポリシーはある) ◦ 性能関連 ◦ コスト関連
改善したこと
通過のための主な実装改善点 ◦ AWS Org設定、マストなアカウント分割 ➢ 監査ログ保存 ◦ S3, RDSの暗号化 ◦
システム用途アクセスキーの撤廃 ◦ 認証情報のSecretsManager移行 ◦ DRテスト環境構築とテスト実施
並行して行ったもの ◦ ベスプラにそったアカウント分割 ➢ ControlTower 等での統合管理 ➢ 個人サンドボックス環境 ◦ SSO
(Googleアカウント->AWS) ◦ SessionManager移行
それぞれの詳細 対応してメリット得られたポイント
改善)アカウント分割 何でも入ってる 闇アカウント ◦ 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
改善)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
改善)S3, RDS暗号化 ◦ 設定から「暗号化を有効」。キーは問わない。 ◦ RDSは運用中に変えるのはかなり厳しい(厳しかった) ◦ S3はデフォルトだけでなく、既存の中身について別途対応 ◦ S3はデフォルト(のデフォルト)無効、RDSはデフォルト有効
改善)システム用途アクセスキーの撤廃 ◦ アクセスキーを使ってはならないわけではないが、 「ローテーション」が必要とされる ➢ 事実上システム用途では使えない ◦ すべてロールへ ◦ CloudTrailのログを見ては、利用箇所をつぶしていく。。。
◦ 万が一の漏洩、に対して強固に
改善)SessionManager移行 ◦ SessionManagerの利用自体はマストではないが、「適切なログの取得と管 理」を実現する上で望ましい。 ◦ ログ管理、SSO連携(合わせてMFA)、VPN+bastionからの脱却 ◦ 初学者への導入コストも激減 VPN bastion
servers servers Session Manager Terminal Browser
改善)認証情報のSecretsManager移行 ◦ 各サービスの認証情報をコードに含めない/専用サービスを用いる ➢ コードからの除外は問題無いが、設定ファイル系が厳しい ◦ 地味に手こずったのがTomcat -> MySQLの認証情報 ➢
コネクションプールを使うために、通常は設定ファイルに直接記載 ➢ 結局専用のDataSourceFactoryを作成 ▪ あまり触れてこなかったこのあたりの動作原理を理解する機会に ◦ こちらも万が一の漏洩、に対して強固に
改善)DRテスト環境構築とテスト実施 ◦ 「RTO, RPOを満たすことを確認できるテスト」 ➢ 単にAZ障害のノード切り替え検証ではなく、総合的なテストが必要 ◦ CloudFormationで疑似環境を再現 ➢ 定期的にやる必要があるため
➢ 復旧時間の検証が目的だと、RDS等のデータサイズも重要 ➢ 実際のテストよりも環境構築に何倍もかかった ◦ 実際確認できた安心感+いつでもテストできる安心感
たたかいの末、、、 通過!(泣)
得られたもの
得られたもの ◦ 改善によって得られた品質・運用改善 ➢ 前述の のとおり ◦ 箔 ➢
バッジ(ちょっとシンプル、、) ◦ MDF(FTR以外にも条件はある) ◦ 「向き合って」得られた知見・自信
MDF (Marketing Development Funds) ◦ (弊社の場合) ◦ AWSパートナー向け資金提供プログラムのひとつ ➢ FTR通過
→ APNソフトウェアパスにて「認定ソフトウェア」となり適用 ◦ 「マーケティングコンシェルジュサービス」 ➢ 対象ソフトウェアの販促活動についての相談/支援窓口 ◦ マーケティングプランを作成→その活動を行うための資金援助 ➢ 割とあらゆる販促活動で適用可能
「向き合って」得られた知見・自信 ◦ システムはどのような品質上の観点を持つべきか、そしてその観点のため にどのような具体解があるのかを理解できた ➢ 永続的な鍵文字列を持たないためにロールやSecretsManagerがある ➢ 適切な権限付与のためにアカウントを分割する ➢ SessionManagerは適切なログ管理のためでもある
◦ これらは、単にFTRを「通過する」だけでなく、きちんと「向き合う」こと で得られる ➢ 単に手法のみに従うだけではもったいない ➢ AWSに限らず汎用的なベストプラクティスとして昇華できる ◦ (結果、担当者はその後SAP、SCSを取得できました)
これからの方につたえたいこと ◦ 通過だけを目指さず、きちんと向き合ってほしい ➢ FTRと、だけでなく、自分たちのシステムと、でもあります。 ➢ このような儀式をきっかけに使わないとなかなか取り組めない内容。 ◦ といいつつ、とりあえず受けておくとよいです ➢
FTR設問項目自体にも改善の余地は多いように思います。 ➢ 受診が増えるとフィードバックも増え、FTR自体の品質があがると思います。 ◦ あとから対応がしんどいやつに気をつけましょう ➢ S3/RDSの暗号化、ロール徹底、ログの統制(CloudTrail, SessionManager等) ➢ DRテスト対策。環境構築をCloudFormationでやるとよさげ。 ◦ 「必要条件」であり「十分条件」ではない ➢ 問われない観点も多い
Thanks!! @accakr https://www.facebook.com/acclegato Contact me! https://meety.net/matches/IkJnFtIEsMjG もちろん エンジニアさん 募集中
FAQ ◦ いちばんしんどかった項目は ➢ 作業量的にはDR対応、サービス影響はRDS暗号化、難易度的にはSecretsManager対応 ◦ 今後の課題は ➢ 機能要件側のベスプラ化、EC2脱却、インシデント管理の効率化、などなど、、、 ◦
反省点 ➢ 観点はSIerの知見を使えるが、実装はAWSのお作法にきちんと従うべき。力技するな。