Upgrade to Pro — share decks privately, control downloads, hide ads and more …

スタートアップ入社4日目までに考えたAWSのセキュリティ向上/ Startup AWS Sec...

スタートアップ入社4日目までに考えたAWSのセキュリティ向上/ Startup AWS Security

shonansurvivors

May 10, 2022
Tweet

More Decks by shonansurvivors

Other Decks in Technology

Transcript

  1. 自己紹介 株式会社スマートラウンド SRE 山原 崇史 (やまはら たかし) 経歴  SIer・銀行・Web系ベンチャー →

    スマートラウンド 好きなAWSサービス  AWS SSO / Organizations Twitter  @shonansurvivors
  2. 会社概要 社名  株式会社スマートラウンド 代表者  砂川 大 設立  2018年5月 従業員数  約25名

    本社住所  東京都渋谷区 ※バーチャルオフィスで全員フルリモート ホームページ  https://jp.smartround.com (サービスLP)
  3. 当社と自分の置かれている状況 プロダクト • smartroundはスタートアップと投資家が利用するプラットフォーム • スタートアップと投資家双方の 機密性の高い情報を保有 これまでの開発体制 • エンジニアは全6名でインフラエンジニアや

    SREは不在 • AWSの構築・管理はCTOとテックリードを中心として兼務で対応 • セキュリティ向上、可用性維持、監視整備、運用自動化などを担える人材を必要としていた 自分 • 一人目のSREとして今月入社
  4. ベストプラクティス 脅威モデリングの利用  対象システムがどのような脅威に晒されているかを洗い出し、  リスク(= 情報資産 × 脅威 × 脆弱性)に基づいて対応優先順位を付ける 「IPA

    セキュアプログラミング講座」を元に作成 (www.ipa.go.jp/security/awareness/vendor/programming) 情報資産の把握 アーキテクチャの把握と分解 脅威の特定 リスクの判定と優先順位付け 脅威の分類には STRIDEなどを利用
  5. 参考 STRIDE • Spoofing Identity (なりすまし) • Tampering with data

    (改ざん) • Repudiation (否認) • Information Disclosure (情報漏えい) • Denial of Service (サービス妨害) • Elevation of Privilege (権限昇格)
  6. 1. Observe(観察) - 有識者へのヒアリング - • 既存のAWSの構成に最も詳しいエンジニアにヒアリング(今回は CTO) • 当初、自分には本番環境・ステージング環境のアカウントの

    IAMユーザーが与えられたが、 ヒアリングの結果、マネジメントアカウント とサンドボックス環境のアカウント も 存在することが確認できた
  7. Tips ヒアリングのコツ あなたがチームでAWSの一般的な知識に最も詳しく、他のメンバーと知識にギャップがある場合、 AWSの正しい用語だけを使って会話していると、逆に 伝わらないかもしれない。別の表現も試そう。 失敗例  自分「Organizationsのマネジメントアカウント に入れるIAMユーザーを下さい」  相手「(マネジメント・・・?) 🤔」

    成功例  自分「各AWSアカウントの親アカウントみたいなやつってありますよね?     全アカウントの請求情報が見れたりするやつです。     そのアカウントに入れる IAMユーザーを下さい」  相手「ありますよ、了解です」
  8. 1. Observe(観察) - 既存AWSリソースの確認 - 前提 • 多くのAWSリソースをコード化済み (IaCツールにはTerraformを利用) •

    一部のAWSリソース(※)は敢えてコード化せず、代わりに作成時の手順とその設定意図を ドキュメントに残す方針としていた ※AWS公式のハンズオンなどを参考に作成した、セキュリティ系のリソースなど 既存AWSリソースの確認方法 • Terraformのコードを眺める(一覧を出力するterraform state listも活用) • 前述のドキュメントを読む • マネジメントコンソールにログインして各画面を参照 ◦ リソース間の繋がりを掴むにはマネジメントコンソールが自分には向いていた
  9. 既存AWSリソース確認作業時に意識したこと 作業時間を有効活用 するため、漫然と各リソースの存在有無や設定を見るのではなく、 セキュリティ的な問題有無を強く意識 して確認した(後述するOrientを一部先行実施したかたち) • ルートユーザーにMFAが設定されているか • CloudTrail, Configは有効化されているか

    • S3が公開されていないか • S3のバージョニングは有効化されているか • EC2用と思われるIAMユーザーが存在しないか(IAMロールを利用するのが適切なため) • プライベートサブネットにあるべきリソースがパブリックサブネットに存在していないか • SSHを利用している場合、踏み台を経由させる構成となっているか • セキュリティグループで不要なアクセスを許可していないか • RDSの自動バックアップ期間は充分か、削除保護が有効になっているか • CloudFront, ALB, VPCのログは取得されているか
  10. 1. Observe(観察) - 構成図の作成 - 背景 • 既存の構成図では全体像を見渡すのに十分ではなかった ◦ VPC外のリソースの記載が無い

    (CloudFront, WAF, S3, Lambda, Codeシリーズ等) ◦ VPC内のリソースも一部記載が欠けている (ElastiCache等) 構成図作成の意義や目的 • ドキュメンテーションもエンジニアリングであり、 Toil(労苦)ではない • 現状把握だけでなく、関係者との今後の情報共有においても価値がある ◦ 将来の新SREメンバーのオンボーディングにも役立つ ◦ AWS JapanのSAさんに求められた時にもぱっと出せる
  11. 2. Orient(状況判断) Observe(観察)によって得られたデータに、前述の判断軸を掛け合わせる。 観察によって得られたデータ 想定インシデント 理由 各開発者はIAMユーザーを使用している アカウント乗っ取り 永続的な認証情報の存在 EC2でIAMユーザーを使用している

    アカウント乗っ取り 永続的な認証情報の存在 S3は全て非公開状態ではあったものの、 ブロックパブリックアクセスが有効ではない 機微情報流出 将来の誤設定 一部のS3のバージョニングが有効ではない データ喪失 将来の誤削除
  12. 3. Decide(意思決定) リスクが高く、優先的に対応すべき脅威に対して、具体的対応内容を決定。 観察によって得られたデータ 想定インシデント 理由 各開発者はIAMユーザーを使用している アカウント乗っ取り 永続的な認証情報の存在 EC2でIAMユーザーを使用している

    アカウント乗っ取り 永続的な認証情報の存在 S3は全て非公開状態ではあったものの、 ブロックパブリックアクセスが有効ではない 機微情報流出 将来の誤設定 一部のS3のバージョニングが有効ではない データ喪失 将来の誤削除 AWS SSO導入 IAMロールの使用 対応内容 設定の有効化 設定の有効化
  13. AWS SSO導入に関する所感やTips 1/2 AWS SSOの初期設定まわり • Google Workspaceを利用する場合の手順は AWS公式ブログが詳しい •

    30〜40分程度で簡単に完了 Google Workspaceでの初期エラーに注意 • 初期設定後に検証で SSOを利用したところ、Google側で403エラーが常に発生 • 数時間後には発生しなくなったので、初期設定後は 1日置いてから作業を再開した方が良いかも
  14. 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を使うと一気に作れて便利
  15. 振り返り 良かった点 • OODAループを採用したことで、事業リスクの高い脅威への対応を 早期に着手できた • Observe(観察)を経て、自社のワークロードに対する理解が深まった 懸念点 • Observe(観察)での収集データが不十分で、より良いDecide(意思決定)ができていないかもしれない

    • Orient(状況判断)での判断軸が不十分で、より良いDecide(意思決定)ができていないかもしれない 懸念点を踏まえて今後改善していきたい点 • AWS Well-Architectedのセキュリティの柱の活用 • SecurityHub, IAM Access Analyzer, Inspector等の導入(マルチアカウントなので Control Towerも)
  16. まとめ • ベストプラクティスは脅威モデリングの実施 ◦ 参考1 : AWS Blog | 脅威モデリングのアプローチ方法

    ◦ 参考2: AWS Builders Online Series | (私のように)セキュリティを何から始めれば良いか分からない開発者の方へ • OODAループは不確実性の高い状況で物事を進めるのに適している ◦ Observe (観察) ◦ Orient (状況判断) ◦ Decide (意思決定) ◦ Act (行動) • AWS SSOは(Organizationsが使えるのであれば )全スタートアップにおすすめしたい