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
スタートアップ入社4日目までに考えたAWSのセキュリティ向上/ Startup AWS Sec...
Search
shonansurvivors
May 10, 2022
Technology
4
4.9k
スタートアップ入社4日目までに考えたAWSのセキュリティ向上/ Startup AWS Security
shonansurvivors
May 10, 2022
Tweet
Share
More Decks by shonansurvivors
See All by shonansurvivors
スタートアップがAWSパートナーになって得られたこと
shonansurvivors
3
850
AWSで構築するCDパイプラインとその改善
shonansurvivors
4
3.4k
Terraformでmoduleを使わずに複数環境を構築して感じた利点
shonansurvivors
4
3.2k
クロステナントアクセスを要件とするsmartroundのマルチテナントSaaSアーキテクチャ
shonansurvivors
0
380
CodeBuildで動かすecspresso
shonansurvivors
2
3.4k
GitHub ActionsのGitHub-hosted Larger Runnersと他サービスと
shonansurvivors
0
900
EC2からのECS移行においてIaCとCDをどう変えたか
shonansurvivors
22
7k
S3とCloudWatch Logsの見直しから始めるコスト削減 / Cost saving S3 and CloudWatch Logs
shonansurvivors
3
2.7k
プロダクトと組織の成長を見据えたスマートラウンドの AWSマルチアカウント戦略/AWS Multi Account Strategy
shonansurvivors
5
4.6k
Other Decks in Technology
See All in Technology
顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed
soudai
24
6.7k
AIを駆使したゲーム開発戦略: 新設AI組織の取り組み / sge-ai-strategy
cyberagentdevelopers
PRO
1
130
20241031_AWS_生成AIハッカソン_GenMuck
tsumita
0
110
話題のGraphRAG、その可能性と課題を理解する
hide212131
4
1.4k
Vueで Webコンポーネントを作って Reactで使う / 20241030-cloudsign-vuefes_after_night
bengo4com
4
2.5k
[AWS JAPAN 生成AIハッカソン] Dialog の紹介
yoshimi0227
0
140
AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book
iselegant
15
3.9k
Apple/Google/Amazonの決済システムの違いを踏まえた定期購読課金システムの構築 / abema-billing-system
cyberagentdevelopers
PRO
1
210
AWS CDKでデータリストアの運用、どのように設計する?~Aurora・EFSの実践事例を紹介~/aws-cdk-data-restore-aurora-efs
mhrtech
4
640
ユーザーの購買行動モデリングとその分析 / dsc-purchase-analysis
cyberagentdevelopers
PRO
2
100
独自ツール開発でスタジオ撮影をDX!「VLS(Virtual LED Studio)」 / dx-studio-vls
cyberagentdevelopers
PRO
1
170
コンテンツを支える 若手ゲームクリエイターの アートディレクションの事例紹介 / cagamefi-game
cyberagentdevelopers
PRO
1
120
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
425
64k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
How GitHub (no longer) Works
holman
311
140k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Six Lessons from altMBA
skipperchong
26
3.5k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
107
49k
Measuring & Analyzing Core Web Vitals
bluesmoon
1
39
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
The Cult of Friendly URLs
andyhume
78
6k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Transcript
株式会社スマートラウンド 山原 崇史(@shonansurvivors) スタートアップ入社 4日目までに考えた AWSのセキュリティ向上
自己紹介 株式会社スマートラウンド SRE 山原 崇史 (やまはら たかし) 経歴 SIer・銀行・Web系ベンチャー →
スマートラウンド 好きなAWSサービス AWS SSO / Organizations Twitter @shonansurvivors
会社概要 社名 株式会社スマートラウンド 代表者 砂川 大 設立 2018年5月 従業員数 約25名
本社住所 東京都渋谷区 ※バーチャルオフィスで全員フルリモート ホームページ https://jp.smartround.com (サービスLP)
事業紹介 ミッション スタートアップが可能性を最大限に発揮できる世界をつくる 課題 1. スタートアップ経営者の多くが初めての起業経験で事務作業に時間を浪費してしまう 2. 投資家の案件・投資先・ファンドの管理はいまもスプレッドシートで行われている 解決策 スタートアップにはマニュアル・テンプレート・ツール
投資家には自動更新される CRMを同時に提供 smartroundが実現する世界 多様なツールと重複するデータを一元化しスタートアップと投資家双方の業務効率をアップ
None
本日のテーマ スタートアップ入社4日目までに考えたAWSのセキュリティ向上 アーリーステージのスタートアップに初の AWS専任者として入社してまだ間もない自分が、 現状をキャッチアップしながら今後どのように優先順位を付けてセキュリティを向上させていくか、 考えたことについてお話しします。 参加者の皆さんも、自身がスタートアップに入社したばかりになった状況を想像して、 考えながら本日のセッションを聞いていただけたら幸いです。
None
本日のスコープ プロダクト以外の 社内ITシステム プロダクト アプリケーション インフラ 独自コード 依存 モジュール AWSリソース
AWSリソース以外
アジェンダ 1. 当社と自分の置かれている状況について 2. ベストプラクティスの検討 3. 実際の取り組み 4. 振り返り 5.
まとめ
1. 当社と自分の置かれている状況
当社と自分の置かれている状況 プロダクト • smartroundはスタートアップと投資家が利用するプラットフォーム • スタートアップと投資家双方の 機密性の高い情報を保有 これまでの開発体制 • エンジニアは全6名でインフラエンジニアや
SREは不在 • AWSの構築・管理はCTOとテックリードを中心として兼務で対応 • セキュリティ向上、可用性維持、監視整備、運用自動化などを担える人材を必要としていた 自分 • 一人目のSREとして今月入社
2. ベストプラクティスの検討
ベストプラクティス 脅威モデリングの利用 対象システムがどのような脅威に晒されているかを洗い出し、 リスク(= 情報資産 × 脅威 × 脆弱性)に基づいて対応優先順位を付ける 「IPA
セキュアプログラミング講座」を元に作成 (www.ipa.go.jp/security/awareness/vendor/programming) 情報資産の把握 アーキテクチャの把握と分解 脅威の特定 リスクの判定と優先順位付け 脅威の分類には STRIDEなどを利用
参考 STRIDE • Spoofing Identity (なりすまし) • Tampering with data
(改ざん) • Repudiation (否認) • Information Disclosure (情報漏えい) • Denial of Service (サービス妨害) • Elevation of Privilege (権限昇格)
懸念点 脅威モデリングをPDCAのPと捉えると、Pが重厚になり、Do着手までに時間がかかりすぎるのでは Do (実行) Check (評価) Act (改善) Plan (計画)
情報資産の把握 アーキテクチャの把握と分解 脅威の特定 リスクの判定と優先順位付け
少し立ち止まって考える 脅威モデリングは設計時のアクティビティ。 入社したばかりの自分はそもそも現状の設計をまだ理解・把握できていない。 そのため、脅威モデリングを行う上で前提となる知識・情報が大きく不足している (土地勘が無い)。 一方で、ワークロードは設計段階ではなく、 既に本番環境で運用されている 。 いまは、リスクの高い脅威からできるだけ 早期に対応していくことが求められると考えた。
3. 実際の取り組み
OODA(ウーダ)ループの採用 元々は航空戦に臨むパイロットの意思決定を対象としたプロセス。ビジネス等でも活用されている。 環境が不安定な中、 不確実性の高い状況で物事を進める ことに向いている。 「高橋 正和 (2017) CISOハンドブック」を元に作成 Observe
(観察) Orient (状況判断) Decide (意思決定) Act (行動) ありのままの データを収集 得られたデータを 知識や経験をもとに 「情報」へと加工
1. Observe(観察) タイムボックス(制限時間)を定めて、観察(データ収集)を実施 • 有識者へのヒアリング • 既存AWSリソースの確認 • 構成図の作成
1. Observe(観察) - 有識者へのヒアリング - • 既存のAWSの構成に最も詳しいエンジニアにヒアリング(今回は CTO) • 当初、自分には本番環境・ステージング環境のアカウントの
IAMユーザーが与えられたが、 ヒアリングの結果、マネジメントアカウント とサンドボックス環境のアカウント も 存在することが確認できた
Tips ヒアリングのコツ あなたがチームでAWSの一般的な知識に最も詳しく、他のメンバーと知識にギャップがある場合、 AWSの正しい用語だけを使って会話していると、逆に 伝わらないかもしれない。別の表現も試そう。 失敗例 自分「Organizationsのマネジメントアカウント に入れるIAMユーザーを下さい」 相手「(マネジメント・・・?) 🤔」
成功例 自分「各AWSアカウントの親アカウントみたいなやつってありますよね? 全アカウントの請求情報が見れたりするやつです。 そのアカウントに入れる IAMユーザーを下さい」 相手「ありますよ、了解です」
1. Observe(観察) - 既存AWSリソースの確認 - 前提 • 多くのAWSリソースをコード化済み (IaCツールにはTerraformを利用) •
一部のAWSリソース(※)は敢えてコード化せず、代わりに作成時の手順とその設定意図を ドキュメントに残す方針としていた ※AWS公式のハンズオンなどを参考に作成した、セキュリティ系のリソースなど 既存AWSリソースの確認方法 • Terraformのコードを眺める(一覧を出力するterraform state listも活用) • 前述のドキュメントを読む • マネジメントコンソールにログインして各画面を参照 ◦ リソース間の繋がりを掴むにはマネジメントコンソールが自分には向いていた
既存AWSリソース確認作業時に意識したこと 作業時間を有効活用 するため、漫然と各リソースの存在有無や設定を見るのではなく、 セキュリティ的な問題有無を強く意識 して確認した(後述するOrientを一部先行実施したかたち) • ルートユーザーにMFAが設定されているか • CloudTrail, Configは有効化されているか
• S3が公開されていないか • S3のバージョニングは有効化されているか • EC2用と思われるIAMユーザーが存在しないか(IAMロールを利用するのが適切なため) • プライベートサブネットにあるべきリソースがパブリックサブネットに存在していないか • SSHを利用している場合、踏み台を経由させる構成となっているか • セキュリティグループで不要なアクセスを許可していないか • RDSの自動バックアップ期間は充分か、削除保護が有効になっているか • CloudFront, ALB, VPCのログは取得されているか
1. Observe(観察) - 構成図の作成 - 背景 • 既存の構成図では全体像を見渡すのに十分ではなかった ◦ VPC外のリソースの記載が無い
(CloudFront, WAF, S3, Lambda, Codeシリーズ等) ◦ VPC内のリソースも一部記載が欠けている (ElastiCache等) 構成図作成の意義や目的 • ドキュメンテーションもエンジニアリングであり、 Toil(労苦)ではない • 現状把握だけでなく、関係者との今後の情報共有においても価値がある ◦ 将来の新SREメンバーのオンボーディングにも役立つ ◦ AWS JapanのSAさんに求められた時にもぱっと出せる
2. Orient(状況判断) リスクの高い脅威から 早期に対応していくため、 優先付けの判断軸を 「事業の存続を揺るがすレベルのインシデント」 が発生しそうかどうか、とした。 具体的には以下5点。 • アカウント乗っ取り
• 機微情報流出 • データ喪失 • システムダウン • Webページ改ざん
2. Orient(状況判断) Observe(観察)によって得られたデータに、前述の判断軸を掛け合わせる。 観察によって得られたデータ 想定インシデント 理由 各開発者はIAMユーザーを使用している アカウント乗っ取り 永続的な認証情報の存在 EC2でIAMユーザーを使用している
アカウント乗っ取り 永続的な認証情報の存在 S3は全て非公開状態ではあったものの、 ブロックパブリックアクセスが有効ではない 機微情報流出 将来の誤設定 一部のS3のバージョニングが有効ではない データ喪失 将来の誤削除
3. Decide(意思決定) リスクが高く、優先的に対応すべき脅威に対して、具体的対応内容を決定。 観察によって得られたデータ 想定インシデント 理由 各開発者はIAMユーザーを使用している アカウント乗っ取り 永続的な認証情報の存在 EC2でIAMユーザーを使用している
アカウント乗っ取り 永続的な認証情報の存在 S3は全て非公開状態ではあったものの、 ブロックパブリックアクセスが有効ではない 機微情報流出 将来の誤設定 一部のS3のバージョニングが有効ではない データ喪失 将来の誤削除 AWS SSO導入 IAMロールの使用 対応内容 設定の有効化 設定の有効化
4. Act(行動) Decide(意思決定)で採択された方針に基づいて、実際に行動する。 • AWS SSOの導入 • EC2でのIAMロールの使用 • S3のブロックパブリックアクセスの有効化
• S3のバージョニングの有効化 👉 AWS SSOの導入は完了しているため、これについて少しお話しします。
AWS SSO導入に関する所感やTips 1/2 AWS SSOの初期設定まわり • Google Workspaceを利用する場合の手順は AWS公式ブログが詳しい •
30〜40分程度で簡単に完了 Google Workspaceでの初期エラーに注意 • 初期設定後に検証で SSOを利用したところ、Google側で403エラーが常に発生 • 数時間後には発生しなくなったので、初期設定後は 1日置いてから作業を再開した方が良いかも
AWS SSO導入に関する所感やTips 2/2 AWS SSOでのAWS CLIの利用は簡単・快適 • 初期設定は、aws sso configure
--profile {profile_name} • 以降は、aws sso login --profile {profile_name} を実行後、ブラウザが起動し、 1クリックで認証完了 Terraformユーザーへ • SSOユーザーやグループは Terraformでの作成に非対応なのでマネジメントコンソールでの作成要 • 許可セットと「AWSアカウント・許可セット・ SSOグループの紐付け情報」は Terraformで作成可 • github.com/cloudposse/terraform-aws-ssoという3rd party moduleを使うと一気に作れて便利
4. 振り返り
振り返り 良かった点 • OODAループを採用したことで、事業リスクの高い脅威への対応を 早期に着手できた • Observe(観察)を経て、自社のワークロードに対する理解が深まった 懸念点 • Observe(観察)での収集データが不十分で、より良いDecide(意思決定)ができていないかもしれない
• Orient(状況判断)での判断軸が不十分で、より良いDecide(意思決定)ができていないかもしれない 懸念点を踏まえて今後改善していきたい点 • AWS Well-Architectedのセキュリティの柱の活用 • SecurityHub, IAM Access Analyzer, Inspector等の導入(マルチアカウントなので Control Towerも)
5. まとめ
まとめ • ベストプラクティスは脅威モデリングの実施 ◦ 参考1 : AWS Blog | 脅威モデリングのアプローチ方法
◦ 参考2: AWS Builders Online Series | (私のように)セキュリティを何から始めれば良いか分からない開発者の方へ • OODAループは不確実性の高い状況で物事を進めるのに適している ◦ Observe (観察) ◦ Orient (状況判断) ◦ Decide (意思決定) ◦ Act (行動) • AWS SSOは(Organizationsが使えるのであれば )全スタートアップにおすすめしたい
スマートラウンドでは新しいメンバーを募集中です! 私たちと一緒にスタートアップが可能性を最大限に発揮できる世界をつくりませんか? jobs.smartround.com