ガバメントクラウドにおけるクラウドセキュリティについて考える

Transcript

1. ガバメントクラウドにおける クラウドセキュリティについて 考える 2024.2.15 藤澤 亮平 1
2. ⾃⼰紹介 藤澤 亮平 - Work at - 株式会社 Fusic （フュージック） 技術開発第⼆部⾨ 所属 - ソフトウェアエンジニア - Skill - Ruby / Rails / Hanami - React / TypeScript - Terraform / CloudFormation / CDK - Career - 2023 Japan AWS Jr.Champtions - SNS - Twitter: @potaku_dev - Github: fujisawaryohei 2 image
3. 余談 最近美容にハマっていてTwitterでは 美容ツイートしかしていないので そろそろ技術的な発信も再開していきた いお気持ち、、 3
4. 伝えたい事 ・ガバメントクラウドでは事前に施されているセキュリティ対策によって ⽣まれる技術的制約が存在する ・その上でセキュリティやネットワークなど様々な観点で満たすべき ⾮機能要件が多く存在する ・そういった意味でガバメントクラウドはとても難しい、、が ガバメントクラウドの要件や技術的制約を把握しておくことで 堅牢なインフラ環境の構築スキル向上に繋がり、クラウドセキュリティの 勉強にもなるためある程度把握しながら勉強しておくと良さそう 4
5. なぜガバメントクラウドなのか︖ ・2025年度末までに⾃治体は基幹業務である税や住⺠基本台帳などの 全20業務をガバメントクラウドへ移⾏するよう進める必要がある ・つまり今後、⾃治体標準化の流れが今後加速していくため、ガバメントクラウドで 事前に実施されているセキュリティ対策や⾮機能要件についてもある程度把握して おき、その上で対策についても考えたほうが良いと考えた ・ガバメントクラウドで施されているセキュリティ対策により⽣まれる 技術的制約により、提案・構築フェーズで上⼿く進みづらい課題がある ・ガバメントクラウドの技術的制約を知る事で、上記の課題をクリアしつつ クラウドセキュリティ対策の学習にも繋がると感じた 5
6. 01 ガバメントクラウドとは︖
7. ガバメントクラウドとは︖ ガバメントクラウドとは政府共通の クラウドサービスの利⽤環境。 クラウドサービスの利点を最⼤限に 活⽤する事で迅速、柔軟、かつセキュ アでコスト効率の⾼いシステム構築を 可能とし、利⽤者によって利便性の⾼ いサービスをいち早く適⽤し改善して いくことを⽬的として構築されている。 2025年度末までに⾃治体はガバメント クラウドへ⾃治体システム20業務を 移⾏しなければならないとなっている。 7 参考: https://xtech.nikkei.com/atcl/nxt/column/18/00001/07231/
8. 普段利⽤しているクラウドとガバメントクラウドの違い 普段利⽤しているパブリッククラウドとは異なりガバメントクラウドでは 政府共通で利⽤するクラウド環境として必要なガバナンスやガードレールが 払い出されるAWSアカウントに対して適⽤されており、それらのAWSアカウントは マルチアカウントで管理されている。 8 この層が 追加されている
9. 利⽤⽅式とアーキテクチャについて ⾃治体や政府が利⽤しているシステムをガバメントクラウド上に移⾏する場合、基本的にはASP、ガバメントクラ ウド運⽤管理補助者(インフラ構築を担当する事業者)といった⽴ち位置を外部ベンダーに委託して任せる形となる。 複数の公共団体が同⼀の運⽤管理補助者（ベンダー）に対して委託をして運⽤を⾏う事を共同利⽤⽅式と呼ばれる。 1つの公共団体が⾃らガバメントクラウドの運⽤管理を⾏う、または運⽤管理を1つの運⽤管理補助者（ベンダー） に対して委託をして運⽤を⾏う事を単独利⽤⽅式と呼ばれる。 共同利⽤⽅式では、委託元の⾃治体のAWSリソースをどこまで専有して利⽤するかという観点から主に以下の3つ のアーキテクチャが存在する。 ⾃治体毎に単独・共同利⽤⽅式の選択が可能で選択する⽅式によってAWSリソースの利⽤⽅法や利⽤料が異なって くる。 9 ⽅式 性質 アカウント分離⽅式 ⾃治体がAWSアカウント毎に分かれている ネットワーク分離⽅式 ⾃治体がAWSアカウントを共通利⽤していて, VPC毎に分かれている アプリケーション分離⽅式 各⾃治体でAWSアカウントもVPCもデータベースも共通利⽤する
10. Point ・ガバメントクラウドとは政府共通のクラウドサービスの利⽤環境 ・事前に予防的統制・発⾒的統制のガードレールが適⽤されている ・⾃治体毎に単独・共同利⽤⽅式の選択が可能で選択する⽅式によって AWSリソースの利⽤⽅法や利⽤料が異なってくる
11. 02 ガバメントクラウドにおける クラウド環境の技術的制約
12. ガバメントクラウドの技術的制約(SCP) 12 ①デジタル庁で管理
13. ガバメントクラウドの技術的制約(SCP) 13 ②運用管理用 アカウントであれば IGWの作成が可能
14. ガバメントクラウドの技術的制約(SCP) 14 ③デジタル庁保有の Organizationsから アカウントが 払い出されるため 集約系の機能の利用 ができない
15. ガバメントクラウドの技術的制約(SCP) 15 ④ IAM Identity Center で払い出され た管理者権限セット でのみIAMユーザー の発行が可能
16. ガバメントクラウドの技術的制約(SCP) 16 ⑤管理者権限セット でもIAMユーザーに 対して AdministratorAccess の権限の付与ができ ない
17. ガバメントクラウドの技術的制約(SCP) 17 ⑥アクセスキー、シ ークレットアクセス キーの発行ができな い ローカル環境でAWS CLIの実行ができな い
18. Point ・ガバメントクラウドには通常のインフラ構築の際と⽐較すると 技術的制約が多い ・細かく⾮機能要件も定められており、制約下の中でこれらの⾮機能要件を 満たすためにネットワーク構成やセキュリティ対策については検討する 必要がある 次題では、ガバメントクラウドにおける、ネットワークやセキュリティ⾯に おいて検討しているアーキテクチャやセキュリティ対策について共有します
19. 03 ガバメントクラウド上で 検討してみたネットワーク構成や セキュリティ対策について
20. TransitGatewayとPrivateLinkについて ガバメントクラウドでは以下のような⾮機能要件が存在する。 ・参加団体側のIPアドレス設計との兼ね合いでCIDRが重複する事も想定されるため、 その際はサービス側で回避する事ができるよう設計する事 参加団体環境間で利⽤しているIP帯に重複が発⽣する事があるため、重複が発⽣した 場合においてもルーティングできる必要があるといった要件。 この場合、TransitGatewayとPrivateLinkを利⽤する事で回避する事ができる。 VPC Lattice を利⽤しても上記課題の解決が可能。 20
21. 予防的統制・発⾒的統制について ガバメントクラウドでは発⾒的・予防的ガードレールが既に適⽤されている。 これらのガードレールは、CDKベースで作成されたテンプレート（⾃動適⽤テンプレート） を利⽤して適⽤されている。 またこれらの事前に有効化されたサービスを利⽤して変更イベント・セキュリティイベント の検出結果のハンドリングを⾏う必要があるが、これもCDKベースで作成されたテンプレー ト（必須適⽤テンプレート）が⽤意しており、これを適⽤する事でこれらのイベントのハン ドリング、通知機能の適⽤を⾏ってくれる。 21 テンプレート名 実行者 AWSサービス 役割 自動適用テンプレート デジタル庁 SecurityHub AWS BestPractices, CIS BenchMark の Findings を収集 GuardDuty VPC Flow Logs, DNS クエリログ, CloudTrail 管理イベントログ, その他もろもろのサービスの Findings を収集 Config 変更管理 CloudTrail API Callなどの管理イベントログのロギング EventBridge GuardyDuty, SecurityHub, Config のコンプライアンスステータス監視 SNS, Lambda EventBridgeの発火先, ChatBotへメッセージ通知する ChatBot 運用者メールアドレスへの通知 必須適用テンプレート ガバメントクラウド 運用管理補助者 SNS Slackへのセキュリティイベントの通知 ChatBot CDK実行時のパラメーターに基づいてSlack or メールアドレス宛てに通知を飛ばす BLEA
22. 予防的統制・発⾒的統制について BLEA（Baseline Environment on AWS） デジタル庁から払い出されたアカウントで適⽤されているテンプレート。ControlTowerにより、予防的ガードレー ルや発⾒的ガードレールが事前に適⽤されている。またBLEAで適⽤されるガードレールはカスタマイズが可能。払 い出されたAWSアカウントで既に以下に記載されている「管理タスク」部分が適⽤されている。 22
23. 予防的統制・発⾒的統制について 23 参考: NRI Secure Blog「【解説】NISTサイバーセキュリティフレームワークの実践的な使い方」 識別 防御 検知 対応 復旧 守るべきデータ, サーバーの識別・検討 ,,etc 保管しているデータの暗号化や サーバーの防御 ,,etc ログの保管や検知機構やSIEM の導入 ,,etc インシデントレスポンス デジタルフォレンジック マルウェア分析 ,,etc インシデント発生対象のサー バーの復旧 ,,etc CSF（Cyber Cecurity FrameWork）とは、米国国立標準研究所（National Institute of Standards and Technology, NIST）が2014年に発行 したサイバーセキュリティフレームワーク。 PCI・DSSやISMS, CIS Controlsと比較して汎用的でかつ体系的なセキュリティ対策を行う事ができる。 CSFの観点から見ても、「識別・防御・検知」においては既に対策されている箇所が多いと考えられる。
24. 予防的統制・発⾒的統制について 24 一方でSecurityHubで検出されている以下2つの基準はある程度クリアしておく必要はあると考えている。 ・CIS AWS Foundations Benchmarks ・AWS Security BestPractices ※ こちらは私の個人アカウントで検証したスコアです
25. 予防的統制・発⾒的統制について 25 ・デジタル庁から払い出されているAWSアカウントは既にディフェンシブセキュリティ対策が ⾏われている ・⼀⽅でSecurityHubのスコアリングは⾼い値を維持しておく必要はある ・上記の事から重点的に検討すべきセキュリティ対策は以下2種類になってくると考えている 1. 「識別」「防御」「検知」観点でマネージドサービス以外のAWSサービスに対する セキュリティ対策 例: アプリの脆弱性対策, サーバー内部におけるログベースの動的な検知や不正プロセス監視、 パッチ適⽤やウイルススキャン等 「復旧」「対応」等のセキCloudWatch 異常検出とか、GuardDuty EC2 Runtime Monitoringとか利⽤できないかと ひっそり考えています、、 2. ュリティインシデント発⽣時の運⽤フローの整理
26. パッチ・アップデート適⽤について サーバーがEC2の場合、パッチ適⽤やアップデートの適⽤を⾏う必要がある。 この時、Patch Managerの利⽤を⾏うことで⾃動化したいが、IGWのない閉域環境でパッチ の取得やウイルス定義ファイルの取得を⾏う事ができない。 これらの技術的成約の中で上記の⾮機能要件を満たすためにWSUSを採⽤。 WSUSのスタンドアロンモデルを内部プロキシーサーバーとして利⽤しつつ、 「どのパッチがどのサーバーで適⽤されているか」といった部分の閲覧・管理は Patch Managerで⾏えるよう以下のような設計を検討している。 26
27. Point ・参加団体の環境の事情に依存しないネットワーク設計を⾏う必要がある ・ガバメントクラウドで払い出されたAWSアカウントには発⾒的・予防的ガー ドレールが既に存在しているため、検討すべきディフェンシブセキュリティの範 囲は限定されている ・SCPによる技術的成約を把握しながらセキュリティ対策を⾏う必要がある
28. まとめ ガバメントクラウドではデジタル庁が保有しているOrganizationsのメンバアカウントとしてアカウント が払い出される Point 2 アプリケーション分離⽅式においてはネットワーク構成が複雑になりがちなため、IP帯の設計は慎重に Point 3 払い出されたアカウントではBLEAが適⽤されているため、予防的・発⾒的ガードレールが既に適⽤され ている。「対応」「復旧」を重点的に検討する必要あり。 Point 4 SCPによる技術的制約の中で様々な⾮機能要件を満たすための⼯夫が必要。そのためにどういった技術的 制約が存在し、その上でどのように対応するか検討する必要がある。 28 Point 1
29. ご清聴いただきありがとうございました Thank You We are Hiring ! https://recruit.fusic.co.jp/