20241012_社内セキュリティチェックリストのAWS前提での書き直しと、リストに準拠した自動チェックの実装

JAWS Festa 2024 in 広島
https://jawsfesta2024.jaws-ug.jp/

Transcript

1. 社内セキュリティチェックリストのAWS前提での書き直しと、 リストに準拠した自動チェックの実装 1 JAWS FESTA 2024 in 広島 ダイキン工業 TICデータ活用推進G 角田潤也
2. 2 自己紹介 角田 潤也 (Junya Tsunoda) • ダイキン工業株式会社 テクノロジー・イノベーションセンター(R&D) • 実行支援チーム（ITインフラ整備/セキュリティ整備/開発チーム支援） 業務：R&DのAWSアカウント100超を管理 ↑をAWS Control Tower/Config/CDK/(GitHub)等で効率化したい 経歴： • 2019年： 新卒入社(工学部 非情報系) • ～2020年度上期： ダイキン情報技術大学 • 2020年度下期： AWSベンダーに長期出張 • 2021年度～： 現所属に（現在6年目)
3. 3 ダイキン工業をあらわすキーワード 創業1924年 100年の歴史 人を基軸に おく経営 空調機器と冷媒を 両方手がけている 総合空調メーカー グローバル生産拠点 110ヵ所以上 全社売上高 4兆円以上 従業員 9.6万人 海外従業員比率は8割以上 170ヵ国以上へ 事業展開 海外売上高比率 85％
4. 4 社内外との協創を通じたイノベーションの加速 ▪ 総床面積：約5.8万㎡、6 階建て ▪ 所在地： 大阪府摂津市（当社淀川製作所内） ▪ 投資額： 約380億円 ▪ 開所： 2015 年11 月25日 ▪ 人員数： 700人規模 産学・研究機関と新たな空気価値創造の取り組み 「空気の価値化」を実現する未来技 術やビジネスモデルを東京大学の教 員陣3,000人や東大発のベンチャー 企業群とともに創出し社会実装する 「ダイキン情報技術大学」を設立、AI・ IoT人材を大阪大学教員と共に育成。ま た、新キャンパス（箕面）を舞台に次世代 スマートビルの実現もめざす 他社との主な取り組み ものづくりに必要な「技能伝承」 にAIを活用。品質の安定や生産性 向上、人材育成を推進 異業種20社以上で知的生産性向上を実現する「未来のオ フィス空間」づくりをめざした『CRESNECT』プロジェクト の一環。パナソニック、オカムラ、ライオン、TOTOなどの社 員が中心となり、IoTを駆使してサービスを開発 技術開発拠点 テクノロジー・イノベーションセンター（TIC） 日立製作所 Point０ 京都大学 「ニューノーマル時代を見据えた研究 開発テーマ」を掲げ、ヘルスケアやエネル ギーからアジア・アフリカ地域研究まで幅 広い領域で成果創出に取り組む 大阪大学 東京大学
5. 5 本セッションで話すこと ▪社内セキュリティチェックリストのAWS前提での書き直し • なぜ書き直しが必要だったか？ • リストを「誰でも一定の基準で対応できるよう改修」するために、何をしたか？ ▪リストに準拠した自動チェックの実装 • なぜ自動チェックが必要だったか？ • 自動チェックになぜカスタムルールが必要か？ • カスタムルールをAWSマネージドサービスで実装・運用する方法の概要 ▪話さないこと • カスタムルールのロジック記述方法の詳細 • 別のイベントで話しています CLOSING EVENT – Cloud Operator Days Tokyo 2024 (cloudopsdays.com)
6. なぜ、社内セキュリティチェックリストの書き直しが必要だったか？ 背景①クラウド活用の高まり • 5か年計画が「ソリューション」中心 • クラウド上で俊敏に開発したい 背景②「ダイキン情報技術大学」出身の若手が開発 • 新入社員が2年間「企業内大学」でITを学ぶ • 400人↑が修了、今までITと縁がない部署にも配属される 若手が読むと誤読のリスクあり 全社IT部門の作成した、社内基準とのギャップ オンプレミス前提で書かれた、有識者でないとわからないリスト AWSの場合、読み替えが必要 通常業務を2年間免除、ダイキンは企業内 大学で「Π型人材」を徹底育成 | 日経クロ ステック（xTECH） (nikkei.com) はたして「タダ飯食らい」だったのか、ダイキ ンのAI社内大学がもたらしたもの | Japan Innovation Review powered by JBpress (ismedia.jp)
7. リストをどう書き直すか？ • AWS前提 ＆ 誰でも一定の基準で対応できるリスト • リストに準拠した自動チェックシステム を 作成し、社内に普及させたい！ 今回は、Webアプリケーションを対象にしたリストについて上記作業を実施 （ 「ダイキン情報技術大学」人材が一番よく使うリスト） 若手が読むと誤読のリスクあり オンプレミス前提で書かれた、有識者でないとわからないリスト AWSの場合、読み替えが必要 必要な理由は後述
8. 8 2023 2024 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 ▪AWS前提＆誰でも一定の基準で対応できるよう改修したリスト リスト本文 （対応方法） の作成 AWSで準拠 できるかの技術調査 対象読者の調整 リストの調整 R&D→全社IT部門レビュー依頼 文章改良：「設定意図」追記 ケーススタディ（実ユーザーテスト） R&D→全社IT部門の再レビュー ▪リストに準拠した自動チェックシステム開発 自動チェックツール調査 カスタムルールの作成 ダッシュボードの作成 ケーススタディ（実ユーザーテスト） 発 行 OpenSearchで作成・権限周りで挫折 QuickSightで再作成 リスト自体が曖昧で、 うまく自動化できず →リスト自体の修正へ 改良版を 反映 カスタム必要とわかる 「設定意図」追記は、 初学者からも経験者からも好評 手応えを感じ始める 社内向けリリースまでの道のり 今年中には実ユーザーテストを完了し、広く公開したい 対象読者の設定や、 それに伴うリスト調整に時間を要した 技術面は早々に OKもらった
9. 9 2023 2024 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 ▪AWS前提＆誰でも一定の基準で対応できるよう改修したリスト リスト本文 （対応方法） の作成 AWSで準拠 できるかの技術調査 対象読者の調整 リストの調整 R&D→全社IT部門レビュー依頼 文章改良：「設定意図」追記 ケーススタディ（実ユーザーテスト） R&D→全社IT部門の再レビュー ▪リストに準拠した自動チェックシステム開発 自動チェックツール調査 カスタムルールの作成 ダッシュボードの作成 ケーススタディ（実ユーザーテスト） 発 行 OpenSearchで作成・権限周りで挫折 QuickSightで再作成 リスト自体が曖昧で、 うまく自動化できず →リスト自体の修正へ 改良版を 反映 カスタム必要とわかる 「設定意図」追記は、 初学者からも経験者からも好評 手応えを感じ始める 社内向けリリースまでの道のり 今年中には実ユーザーテストを完了し、広く公開したい 対象読者の設定や、 それに伴うリスト調整に時間を要した 技術面は早々に OKもらった
10. 10 2023 2024 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 ▪AWS前提＆誰でも一定の基準で対応できるよう改修したリスト リスト本文 （対応方法） の作成 AWSで準拠 できるかの技術調査 対象読者の調整 リストの調整 R&D→全社IT部門レビュー依頼 文章改良：「設定意図」追記 ケーススタディ（実ユーザーテスト） R&D→全社IT部門の再レビュー ▪リストに準拠した自動チェックシステム開発 自動チェックツール調査 カスタムルールの作成 ダッシュボードの作成 ケーススタディ（実ユーザーテスト） 発 行 OpenSearchで作成・権限周りで挫折 QuickSightで再作成 リスト自体が曖昧で、 うまく自動化できず →リスト自体の修正へ 改良版を 反映 カスタム必要とわかる 「設定意図」追記は、 初学者からも経験者からも好評 手応えを感じ始める 社内向けリリースまでの道のり 今年中には実ユーザーテストを完了し、広く公開したい 対象読者の設定や、 それに伴うリスト調整に時間を要した 技術面は早々に OKもらった
11. 11 「誰でも一定の基準で対応できる」リストを実現する2つの柱 ① 抽象度を下げて、 AWSでの具体的な内容（設定方法や設計意図）を記載 ②執筆体制の強化
12. 12 ①抽象度を下げて、AWSでの具体的な内容（設定方法や設計意図）を記載 項目 補足 通信路を暗号化 しているか？ 重要情報を送受信する場合は、サーバとクライアントの間の通信を暗号化する。 TLSに利用するサーバ証明書は信頼できる機関から発行されたものを利用することが望ましい。 オンプレ/クラウドに共通する概要のみ記載 1.規則 2.規則を遵守す るための選択肢 3-a.各選択肢毎の 実施事項 概要 3-b. 補足 4.規則を設定した意図 インターネット上 の全てのHTTP 通信において、 HTTPSによる 暗号化を有効に しているか？ ①新規構築の場合、 各サービスにて、 ◦◦◦◦以上での 暗号化通信のみ を許可する。 ②… ①HTTPS化手順は… ・ALB:<略> ・CloudFront:<略> … ②で… インターネット上の通信経路においては、通信データ 盗聴リスクがあるため、暗号化が望ましいため、イン ターネット上の通信経路の全暗号化を推奨する。 ▪全暗号化を推奨する理由 ・AWSではマネージドサービスの活用により、比較的 容易にインターネット上の通信経路を暗号化できる。 ・暗号化・非暗号化を共存させると、設定ミスしやすい 具体的なAWSサービス名を記載 文量こそ増えたが、対応しやすさは向上 設定意図を記載 内容が腹落ちした状態での対応が可能 元リスト AWS版リスト 社内の利用状況を基に、主要サービスを中心に対応 CDN/ゲートウェイ ALB CloudFront … サーバー・フロント EC2/ECS Lambda … 認証 Cognito … データベース・ストレージ S3 DynamoDB … 試行錯誤の末、 このスキーマに
13. 13 部長クラス IT全体の担当 課長クラス AWSに親しみあり 担当者 AWSを日常利用 ベンダー 複数企業にて実績あり 全社IT R&D 登壇者ココ ②執筆体制の強化 元々のリストを作成した全社IT部門と、 前提のすり合わせ / 進捗の共有 /各組織でキャッチした利用者の声の反映 を行った 組織 の壁 打ち合わせ Teamsで連携 週1～ 打ち合わせ 月1～ 某ITベンダー AWS専業 隔月～ リストの Excelを お渡しして レビュー いただく 都度 セキュリティ専業 ※ﾍﾞﾝﾀﾞｰではないが ﾌﾟﾛﾌｪｯｼｮﾅﾙｻｰﾋﾞｽとして 元々の リスト作成
14. 14 2023 2024 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 ▪AWS前提＆誰でも一定の基準で対応できるよう改修したリスト リスト本文 （対応方法） の作成 AWSで準拠 できるかの技術調査 対象読者の調整 リストの調整 R&D→全社IT部門レビュー依頼 文章改良：「設定意図」追記 ケーススタディ（実ユーザーテスト） R&D→全社IT部門の再レビュー ▪リストに準拠した自動チェックシステム開発 自動チェックツール調査 カスタムルールの作成 ダッシュボードの作成 ケーススタディ（実ユーザーテスト） 発 行 OpenSearchで作成・権限周りで挫折 QuickSightで再作成 リスト自体が曖昧で、 うまく自動化できず →リスト自体の修正へ 改良版を 反映 カスタム必要とわかる 「設定意図」追記は、 初学者からも経験者からも好評 手応えを感じ始める 社内向けリリースまでの道のり 今年中には実ユーザーテストを完了し、広く公開したい 対象読者の設定や、 それに伴うリスト調整に時間を要した 技術面は早々に OKもらった
15. 15 ケーススタディで何を行ったか ▪対象：R&D部門で運用しているシステム2件＋事業部で運用しているシステム2件 以下条件に基づき選定した • 「ALB+EC2」か「CloudFront+S3」のどちらかを採用するWebシステムを対象とする • 若手のみで開発するシステムと、中堅含めて開発するシステムの両方が対象になるようにする ▪評価箇所 実テーマにリストを適用し、テーマ担当者が以下で困らないかを見てもらう • 「AWS前提 ＆ 誰でも一定の基準」を満たす上で、文章構成・表現の誤りや不足がないか • 具体例①：セキュリティ施策の誤読にともなう、誤った対応をしないか • 具体例②：リストの文章が正しいかだけでなく、読みづらさを感じないか ▪実施結果 多数の指摘を頂いた。 重要度 割合 誤る可能性 詳細 大 8% 高 • 誤った施策が記載されており、誤った施策を実施してしまう 中 41% 中 • 誤りはないが、意図が分かりづらく、誤った対策を実施してしまう。 • 誤りはないが、判断基準がないため、誤った対策を実施してしまう 小 51% 低・なし • 誤字、脱字、情報不足で追加の情報を与える必要がある 実際のテーマに適用しないと見えない粗がある。 時間はかかった(4か月)が、非常に重要な取り組みだった
16. 16 2023 2024 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 ▪AWS前提＆誰でも一定の基準で対応できるよう改修したリスト リスト本文 （対応方法） の作成 AWSで準拠 できるかの技術調査 対象読者の調整 リストの調整 R&D→全社IT部門レビュー依頼 文章改良：「設定意図」追記 ケーススタディ（実ユーザーテスト） R&D→全社IT部門の再レビュー ▪リストに準拠した自動チェックシステム開発 自動チェックツール調査 カスタムルールの作成 ダッシュボードの作成 ケーススタディ（実ユーザーテスト） 発 行 OpenSearchで作成・権限周りで挫折 QuickSightで再作成 リスト自体が曖昧で、 うまく自動化できず →リスト自体の修正へ 改良版を 反映 カスタム必要とわかる 「設定意図」追記は、 初学者からも経験者からも好評 手応えを感じ始める 社内向けリリースまでの道のり 今年中には実ユーザーテストを完了し、広く公開したい 対象読者の設定や、 それに伴うリスト調整に時間を要した 技術面は早々に OKもらった
17. 17 2023 2024 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 ▪AWS前提＆誰でも一定の基準で対応できるよう改修したリスト リスト本文 （対応方法） の作成 AWSで準拠 できるかの技術調査 対象読者の調整 リストの調整 R&D→全社IT部門レビュー依頼 文章改良：「設定意図」追記 ケーススタディ（実ユーザーテスト） R&D→全社IT部門の再レビュー ▪リストに準拠した自動チェックシステム開発 自動チェックツール調査 カスタムルールの作成 ダッシュボードの作成 ケーススタディ（実ユーザーテスト） 発 行 OpenSearchで作成・権限周りで挫折 QuickSightで再作成 リスト自体が曖昧で、 うまく自動化できず →リスト自体の修正へ 改良版を 反映 カスタム必要とわかる 「設定意図」追記は、 初学者からも経験者からも好評 手応えを感じ始める 社内向けリリースまでの道のり 今年中には実ユーザーテストを完了し、広く公開したい 対象読者の設定や、 それに伴うリスト調整に時間を要した 技術面は早々に OKもらった
18. 18 As Is チェックがリリース前に集中 要件定義 設計 開発実装 PoC セキュリティ ジャッジ 修正 運用 To Be 全フェーズでみる 手動チェック ②自動チェック ①自動チェック 手動チェック ②リリース後の 不用意な変更 ①手戻り シフトレフト PoCから都度確認 シフトライト リリース後の変更も追跡 対応工数が増えるので、自動チェックの活用が不可欠 R&D部門の課題：開発フロー内で、いつ社内ルールの準拠状況をチェックするか？ なぜ自動チェックが必要か
19. 19 AWSインフラ 周り アプリ 周り 運用体制 周り 14件 4件 10件 まず、AWS Security Hub（AWS公式で用意された自動チェック）を利用 →社内チェックリストのうち、5/２８件（18%)しか自動化できなかった →カスタムルールで9件を追加対応し、14/２８件（50%)を自動化した ▪社内チェックリスト(２８件）の内訳 未対応 対応 5件 9件 ①Security Hub非対応サービス (認証用のCognito）のルール ②痒い所に手を届かせたいルール 例：デフォルトルールで定義できる 「SGで0.0.0.0/0はNG」では不十分、 「社内からのIP CIDRはNG」までやりたい 例：AND条件やOR条件を扱うルール 「社内からのアクセスに制限するため、 接続元IPアドレス制限 OR 認証した？」 そもそも 自動化不可 なぜ自動チェックにカスタムルールが必要か 定型設定なので 自動化できる 調査中
20. 20 ※：https://github.com/aws-samples/policy-as-code 要件 AWSサービス OSSツール：AWS公式ワークショップ(※)を基に選定 Security Hub AWS製 それ以外 cfn-lint cfn-guard OPA Checkov ルール実装しやすさ 〇:専用言語で書く △:汎用の言語で書く - 実装不可 △ Python 〇 独自DSL 〇 Rego 〇 Yaml チェック 対象 IaCテンプレ × 〇 〇 〇 Regula 〇 実リソース 〇 × 〇 △ × マルチクラウド対応 × × × 〇 〇 カスタムルールをどのツールで実装するか？ 星取表 決め手：IaCテンプレと実リソースのチェックに両対応 IaCテンプレ作成 → コマンドラインでcfn-guard起動 → カスタムルール（CFn用）で評価 ↑ ※記法は同じだが、調整は必要 ↓ 実リソース構築 → AWS Config上に設定状況保存 →カスタムルール（Config用）で評価
21. 21 cfn-guardを実際に用いる場面 ▪SARIF出力機能を使って自動化することで、開発フローに組み込める ▪▪エディタ上 ▪▪ CIツール ①ファイルを保存 ③その場で指摘 ②保存時にcfn-guardが走るよう設定 非準拠時にCI停止 決め手：IaCテンプレと実リソースのチェックに両対応 IaCテンプレ作成 → コマンドラインでcfn-guard起動 → カスタムルール（CFn用）で評価 ↑ ※記法は同じだが、調整は必要 ↓ 実リソース構築 → AWS Config上に設定状況保存 →カスタムルール（Config用）で評価
22. 22 cfn-guardを実際に用いる場面 ▪SARIF出力機能を使って自動化することで、開発フローに組み込める ▪▪エディタ上 ▪▪ CIツール ①ファイルを保存 ③指摘が表示される ②保存時にcfn-guardが走るよう設定 非準拠時にCI停止 決め手：IaCテンプレと実リソースのチェックに両対応 IaCテンプレ作成 → コマンドラインでcfn-guard起動 → カスタムルール（CFn用）で評価 ↑ ※記法は同じだが、調整は必要 ↓ 実リソース構築 → AWS Config上に設定状況保存 →カスタムルール（Config用）で評価 ③指摘が表示される 非準拠時にCI停止 SARIFとは？ 静的解析ツール向けの標準フォーマット 出力結果を後段のツールに渡しやすい SARIF cfn-guard エディタ拡張 CI拡張
23. 23 決め手：IaCテンプレと実リソースのチェックに両対応 IaCテンプレ作成 → コマンドラインでcfn-guard起動 → カスタムルール（CFn用）で評価 ↑ ※記法は同じだが、調整は必要 ↓ 実リソース構築 → AWS Config上に設定状況保存 →カスタムルール（Config用）で評価 cfn-guardを実際に用いる場面 ▪AWS Config上で、cfn-guard記法で書いたルールを動かすことが可能 AWSマネージドな自動チェック基盤としては優秀（チェック用のリソース管理が不要） しかし、表示基盤（マネコン上）としては見づらい 順序がバラバラ（ルール名に数字を入れても無視される） マルチアカウントが大変（アカウント毎にログインが必要） SecurityHubのマネージドルールと混ざる フィルタリングが弱い（準拠/非準拠のみ）
24. 24 2023 2024 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 ▪AWS前提＆誰でも一定の基準で対応できるよう改修したリスト リスト本文 （対応方法） の作成 AWSで準拠 できるかの技術調査 対象読者の調整 リストの調整 R&D→全社IT部門レビュー依頼 文章改良：「設定意図」追記 ケーススタディ（実ユーザーテスト） R&D→全社IT部門の再レビュー ▪リストに準拠した自動チェックシステム開発 自動チェックツール調査 カスタムルールの作成 ダッシュボードの作成 ケーススタディ（実ユーザーテスト） 発 行 OpenSearchで作成・権限周りで挫折 QuickSightで再作成 リスト自体が曖昧で、 うまく自動化できず →リスト自体の修正へ 改良版を 反映 カスタム必要とわかる 「設定意図」追記は、 初学者からも経験者からも好評 手応えを感じ始める 社内向けリリースまでの道のり 今年中には実ユーザーテストを完了し、広く公開したい 対象読者の設定や、 それに伴うリスト調整に時間を要した 技術面は早々に OKもらった
25. 25 ダッシュボードを作ろう ▪AWSマネージドでダッシュボードを自作し、必要な機能を実装している ある程度の運用しやすさを担保しつつ、高い拡張性・安価なランニングコストを実現 ▪アーキテクチャ 自動チェック結果をアカウント跨ぎで集約する為、 Amazon Security Lakeを採用 3rdPartyのSaaSと比べてシステムコストが安価 ・QuickSightの費用： 閲覧者が$3/月/人、編集者が$24/月/人 ・SecurityLakeの費用： R&D部門全体のAWSConfigログを保存しても、～$10/月程度 ダッシュボードはQuickSightを用いることで ノーコード・インフラ管理不要で構築 Athenaでクエリ 自動チェックは 各アカウント上で
26. 26 ダッシュボードを作ろう ▪AWSマネージドでダッシュボードを自作し、必要な機能を実装している ある程度の運用しやすさを担保しつつ、高い拡張性・安価なランニングコストを実現 ▪QuickSight上の画面 アカウント跨ぎで確認 アカウント毎フィルタリングも可能 大本のExcelチェックリストと同じ順序で整列 非準拠の総数を表示 非準拠項目を表示
27. 27 まとめ ▪発表内容 • 社内の急速なIT発展に対応する為、セキュリティチェックリストを作り直した AWS前提で、抽象度を下げた具体的な内容や設計意図を記載 実テーマでのケーススタディを実施 • 社内ルール準拠のAWS自動チェックの実現には、自社向けカスタムルールが必要 • SecurityHubでは社内ルールの18%のみ→カスタムルール作成し50%に対応 • カスタムルール実装には、 IaCを使うチームもそうでないチームも使える、cfn-guardを選定した • カスタムルールを実装するツールとして、cfn-guardを選定した 最大の理由は、IaCテンプレと実リソースに両対応、IaC未普及なチームも使える
28. https://daikin-career.net/jobfind-pc/ 当社が目指す未来を一緒に実現しませんか？ 興味を持った方、是非ご応募ください。 応募ページはこちら ダイキンにはゲンバが沢山あります！ “ダイキン情報技術大学”出身の若手たちと デジタル改革を推進していく ITエンジニア募集！！
29. 29 連絡先 DAIKIN MID-CAREER RECRUITMENT TECHNOLOGY AND INNOVATION CENTER サスティナビリティ レ ポ ー ト ２ ０ ２ ３ 統合報告書２０２３ キャリア採用 研究開発拠点 C S R ・ 環 境 経 営 ・ 財 務 ダイキン公式 SNS