株式会社スマートラウンド 山原 崇史(@shonansurvivors) スタートアップ入社 ４日目までに考えた AWSのセキュリティ向上

自己紹介 株式会社スマートラウンド SRE 山原 崇史 (やまはら たかし) 経歴 　SIer・銀行・Web系ベンチャー → スマートラウンド 好きなAWSサービス 　AWS SSO / Organizations Twitter 　@shonansurvivors

会社概要 社名 　株式会社スマートラウンド 代表者 　砂川 大 設立 　2018年5月 従業員数 　約25名 本社住所 　東京都渋谷区　※バーチャルオフィスで全員フルリモート ホームページ 　https://jp.smartround.com （サービスLP）

事業紹介 ミッション 　スタートアップが可能性を最大限に発揮できる世界をつくる 課題 　1. スタートアップ経営者の多くが初めての起業経験で事務作業に時間を浪費してしまう 　2. 投資家の案件・投資先・ファンドの管理はいまもスプレッドシートで行われている 解決策 　スタートアップにはマニュアル・テンプレート・ツール 　投資家には自動更新される CRMを同時に提供 smartroundが実現する世界 　多様なツールと重複するデータを一元化しスタートアップと投資家双方の業務効率をアップ

No content

本日のテーマ スタートアップ入社4日目までに考えたAWSのセキュリティ向上 　 　アーリーステージのスタートアップに初の AWS専任者として入社してまだ間もない自分が、 　現状をキャッチアップしながら今後どのように優先順位を付けてセキュリティを向上させていくか、 　考えたことについてお話しします。 　 　参加者の皆さんも、自身がスタートアップに入社したばかりになった状況を想像して、 　考えながら本日のセッションを聞いていただけたら幸いです。

No content

本日のスコープ プロダクト以外の 社内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