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

KINTO テクノロジーズの クラウドセキュリティ専門組織の実践知あれこれ

KINTO テクノロジーズの クラウドセキュリティ専門組織の実践知あれこれ

KINTOテクノロジーズにおけるクラウドセキュリティ専門組織の立ち上げから現在までの変遷、組織体制、クラウド環境の特徴、セキュリティ方針、そして具体的な取り組み事例(CSPM/AI-SPMによるガードレール運用、IAM最小権限、脅威検知、GenAI活用など)について、実践的な知見を紹介しています。
クラウドセキュリティやSREに関心のある方、組織のセキュリティ体制強化を検討している方におすすめです。

More Decks by KINTOテクノロジーズ Osaka Tech Lab

Transcript

  1. Tomoaki TADA / 多田 友昭 KINTO テクノロジーズ Cloud Security グループ

    GM • 2022 年 7 月 KINTOテクノロジーズ Join CCoE チーム • 2024 年 4 月 Security CoE グループ 立上げ • 2025 年 7 月 Cloud Seuciry グループ Career • メーカSE@東京:情報収集衛星 画像処理系システム開発 • セキュリティベンチャー@大阪:MSP、SIEM開発 • SIer@大阪:認証基盤開発、クラウド、CCoE、AIOps Community • CCoE 実践者コミュニティ関西 オーガナイザ
  2. クラウド環境とクラウド関連組織 KINTO テクノロジーズのクラウド環境 多くのプロダクトは AWS 環境に構築。本番環境での稼働はまだまだ少ないが、Microsoft Azure、 Google Cloud の環境もある。Azure

    は AOAI、Google Cloud は BQ、Firebase、Vertex AI での利用が多い • プロダクト環境 • prod / dev / stg / sandbox • ECS, Serverlessでの構築 • 最近は、Bedrock 利用増 • 分析、Firebase • prod / dev / stg / sandbox • PoC で Vertex AI 利用 プロダクト数 > 100 サブスク数 〜 20 project数 〜 50 • AOAI 利用のため Azure 選択 • prod / dev / stg / sandbox • PoC フェーズ
  3. クラウド環境とクラウド関連組織 クラウド関連組織の役割 プロダクト 1 プロダクト 2 プロダクト N クラウドプロバイダー(AWS, Azure,

    Google Cloud) クラウドセキュリティ、クラウドアカウント管理 クラウドインフラリソース Platform Engineering CI/CD SAST AppLog MSP DBRE / SRE / O11y App App App データ・プライバシー / セキュリティガバナンス / コンプライアンス 脆弱性診断 / 脅威分析 Cloud Security Cloud Infrastructure Platform Engineering DBRE / SRE 各プロダクト開発チーム • 組織全体のクラウドセキュリティを統制・推進 • マルチクラウド CNAPP、グループポリシー準拠等 Cyber / Information Security • クラウドエンジニアリング、インフラ環境提供 • マルチクラウド、IaC によるシステム構築・変更 • 開発者向けの環境(インフラ・ツール群)の構築 • DevOps 支援、CI/CD、APM・ログ基盤、MSP • Database Reliability、推進 • 全社 SLO/SLI の策定 • 社内規定・ルール整備、法令対応(PII) • CSIRT、グループ全体のセキュリティガバナンス ※実際の人数を表して いません。 あくまでイメージです
  4. クラウド環境とクラウド関連組織 Cloud Security グループ変遷 2022. 07 2022. 09 2024. 04

    2025. 07 Osaka Tech Lab join Platform G 所属 ( セキュリティ ) CCoE チーム立上げ クラウド「統制」を軸に活動 2023. 04 メンバ加入 クラウドセキュリティ専門組織として、 SCoE 立上げ。全社セキュリティ部門と 同部署に Cloud Security Gに名称変更 Cloud Security グループはトップダウンで組成したグループではなく、クラウドセキュリティの課題解決 のためボトムアップで提案し、組成したグループ。現在は、全社セキュリティ組織と同部署内で活動 することで、クラウドセキュリティを全社的な取組として進めている
  5. クラウド環境とクラウド関連組織 セキュリティ方針・考え方 ビジネスのためのセキュリティ であり、 ビジネスを阻害するセキュリティ は NG • グループ会社のグループポリシーに準拠 •

    我々のビジネスや資産、企業文化や組織体制、システム構成などを勘案し、最適なセキュリティ施 策・運用を行う • 何を守るのか、どこに注力するのか、優先順位と濃淡をつける
  6. クラウド環境とクラウド関連組織 CCoE 立上げ時に掲げたミッション プラットG セキュリティT 経営・管理部門 経営層 CIO室 セキュリティプリセット クラウド環境

    アプリ アプリ アプリ 開発G ガードレールレポート クラウド活用ガイドライン 社内規定類 GISS 対応方針① 対応方針② 対応方針③ ベース文書提供 連携・協力 提供 提供・監査・是正 開発 モニタリング・是正 開発Gは適切なポリシーで統制されたクラウドを自由に使うことができる。CCoE が常にセキュリ ティ状態を監査し問題があれば是正する。 活用 統制推進T KINTO開発 グローバル 分析 ・・・ 提供 CCoE CCoE推進
  7. クラウド環境とクラウド関連組織 Cloud Security グループミッション 統制 防御 検知 対応 復旧 Mission

    1 セキュリティリスクを発生させない Mission 2 セキュリティリスクを常に監視・分析する Mission 3 セキュリティリスクが発生した時に速やかに対応する Gen AI 活用 • 発見的ガードレール (CSPM, AI-SPM ) • 脅威検知 • ログ分析, SOC • クラウドセキュリティガイドライン • セキュリティプリセット環境提供 • 予防的ガードレール • IAM 最小権限 • CSIRT • ログ分析 • ガードレールカイゼンドキュメント Cloud Security グループ取組み
  8. Cloud Security グループ 取組み 発見的ガードレール ( CSPM ) CSPM チェック

    CSPM アラート のカイゼン作業 クラウドセキュリティG CSPMカイゼン Doc カイゼンドキュメント 参照 レポート提供+アラート連絡・ カイゼン依頼 CSPMレポート作成 (作成スクリプト) Center for Internet Security やクラウドプロバイダーのセキュリティベストプラクティスを基準に、 リスクのあるクラウドリソースの構成や設定を検知し定期的にレポート プロダクト側ユーザ (セキュリティチャンピオン) CSPM カイゼン Doc作成・提供 ※Google Cloud の例を記載。AWS であれば Security Hub。Azure でればDefender for Cloudを利用して構成チェック MS Defender for cloud 明確に“セキュリティチャンピ オン”ではないが、カイゼンし てくれそうな人をアサイン AWS Security Hub プロバイダーによって 異なるCSPM 製品を運用
  9. Cloud Security グループ 取組み 発見的ガードレール ( CSPM ) レポート提供とアラートカイゼンの依頼は、Slack、Confluence 、

    JIRA チケットで連絡 全てのユーザが他プロダクトの状況も含めてチェックできる アラート詳細 • 担当者 • アラート名 • Severity • 対象リソース • カイゼン方法(リンク) • 抑制依頼(リンク) • など チケット上でクラウドセキュリティGとプロダクト側でコミュニケーションし、 クローズまで行う 各プロジェクトのアラート一覧 (この辺りの仕組みは、レポー トから半自動で作成)
  10. Cloud Security グループ 取組み 発見的ガードレール ( CSPM ) Cloud Security

    グループとして、存在感を如何に示すか!! プロダクト側で積極的にカイゼンを進めてもらうために あの人(あのグループ)に頼まれたら、「仕方がない」と思わせる • Slack の中の人にならないように対面で知り合い、日頃からコミュニケーション • 社内勉強会に登壇しつづける • 外部コミュニティに登壇しつづける
  11. Cloud Security グループ 取組み 発見的ガードレール ( AI-SPM ) OWASP Top

    10 for LLM Application のリスクに対する対応策を AWS, Azure, Google Cloud のサービ スではどのように実装するか。をガイドラインとして策定。勉強会で浸透 https://genai.owasp.org/resource/owasp- top-10-for-llm-applications-2025/ AWS Azure Google Cloud • ユーザからのプロンプトの前文として、 システム指示を実装し、モデルの動作を (ペルソナ、ロール、出力形式等)限定 する • Amazon Bedrock Guardrailsを利用し、入出 力をフィルタリングするAmazon Bedrock ガードレールの仕組み - Amazon Bedrock • LLMへのアクセスは最小権限の原則とす る( AWS IAM ロール) • 高リスクの操作には人間の承認を求める など( Human-in-the-Loop ) • テストに、LLM Injection の項目を追加し 実施する(LLM脆弱性診断など) • プロンプトインジェクションのセキュリ ティ - Amazon Bedrock • AWSセキュリティブログ生成AIワーク ロードをプロンプトインジェクションか ら保護する • ユーザからのプロンプトの前文として、 システム指示を実装し、モデルの動作 (ペルソナ、ロール、出力形式等)を限 定するAzure OpenAI を使用したシステム メッセージを設計する - Azure OpenAI Service • Azure AI Content Safetyを利用し、入出力 をフィルタリングするAzure AI Foundry ポータルの Content Safety の概要 - Azure AI Foundry • LLMへのアクセスは最小権限の原則とす る( Entra ID ) • 高リスクの操作には人間の承認を求める など。( Human-in-the-Loop ) • テストに、LLM Injection の項目を追加し 実施する(LLM脆弱性診断など) • GPTのプロンプトエンジニアリングの手 法についてはこちらを参照するAzure OpenAI Service - Azure OpenAI • ユーザからのプロンプトの前文として、 システム指示を実装し、モデルの動作 (ペルソナ、ロール、出力形式等)を限 定するシステム指示を使用す る | Generative AI on Vertex AI | Google Cloud • safety filtersを利用し、入出力をフィルタ リングするSafety and content filters | Generative AI on Vertex AI | Google Cloud • LLMへのアクセスは最小権限の原則とす る( Google Cloud IAM ) • 高リスクの操作には人間の承認を求める など( Human-in-the-Loop ) • テストに、LLM Injection の項目を追加し 実施する(LLM脆弱性診断など) • プロンプトエンジニアリングやプロンプ ト戦略については、こちらが参考になる プロンプトの概要 | Generative AI on Vertex AI | Google Cloud プロンプト戦略 の概要 | Generative AI on Vertex AI | Google Cloud 各クラウドサービスの対応 策を整理・ガイドライン化 「01 : Prompt Injection」 ※ガイドラインの内容を抜粋(社内勉強会に利用)
  12. Cloud Security グループ 取組み 発見的ガードレール ( AI-SPM ) ガイドラインの対応策をクラウドサービスに設定しているかどうかを、 チェックする

    コントロールを作成し運用中(AWSから) Regoでコントロールを作成 Amazon Bedrock Guardrail の Prompt Injection が 有効化されているかどうかをチェック Sysdig コンソール Sysdig は CSPM のコントロールを Rego で記述できる。製品で提供されないコントロールは、 自分たちで開発し、チェックしている
  13. Cloud Security グループ 取組み IAM 最小権限 ( AWS CI /

    CD アクセスキーの廃止 ) CI / CD 用の IAM ユーザを作成・アクセスキー を利用して、GitHub Actions で CD している アクセスキーの廃止と OIDC への移行を全社に展開し実施中 移行が進まないプロダクトについては、 グループポリシーのアセスメントタイミングで、移行実施を支援することも
  14. Cloud Security グループ 取組み IAM 最小権限 ( PIM / PAM

    ) Google Cloud, Azureについては、広めの権限を与えて、プロダクト側(セキュリティチャンピオン)で適切に 管理してもらう運用としている。とはいえ、高権限のものについては、PIM / PAM 設定 Privileged Identity Management • Contributor • Role Based Access Control Administrator • User Access Administrator Privileged Access Manager • Project IAM 管理者 プロダクト側の生産性を落とさないために、リクエストに基づく承認は、必ずしもCloud Security グループ で実施していない。Cloud Security グループでは、監査ログの保存・確認や 脅威検知による アクティビティチェックを行う サブスクリプション・ プロジェクトの払い出 し時に、PIM / PAM を 事前設定 権限が付与されたユーザ がどのようなアクティビ ティを実施するかは、 脅威検知でリアル確認。 例、Google Cloud で Owner 付与したらプロダクト側 に確認など
  15. Cloud Security グループ 取組み 脅威検知 マルチクラウド環境の脅威をリアルタイム で検知し、アクティビティを分析し問題があれば ( ベストエフォートで実施 )、プロダクト側に通知

    Amazon GuardDuty MS Defender for cloud * クラウドネイティブ環境 向けのOSSのランタイムセ キュリティツール Sysdig は ランタイムセキュリティに Falco を利用している。製品で提供されないルールは、 自分たちで開発し、チェックしている ( CSPM → Rego、Runtime Security → Falco )
  16. Cloud Security グループ 取組み 脅威検知 Google Cloud の脅威検知の一例 ユーザが Service

    Account Key を作成したことをリアル検知、Slack に通知 分析 クラウドセキュリティG 対応? サービスアカウントキーの作成 • ユーザがダウンロード • 有効期限はない プロダクト側ユーザ (セキュリティチャンピオン) 検知 連絡 確認 Yes 対応 ユーザ側での適切な管理が必要 不正アクセス/情報漏えい リソースへの攻撃(サービス停止) 経済的損失 など Workload Identity 連携 使えますか? サービスアカウントキーを発行せずにアクセス権付与。AWS, Azure, GitHubなどのOIDCサポートで利用可能
  17. Cloud Security グループ 取組み 脅威検知 Service Account Key は多くのグループで課題になることが多い。 そもそも、キーを極力発行してもらわないように

    プロダクト側からヨコテンしてもらう プロダクト側ユーザ (セキュリティチャンピオン) ・ ・ ・ ・ クラウドセキュリティG ・ ・ ・ Workload Identity の利用促進、 勉強会実施、個別フォローなど • プロダクト側ユーザに、勉強会で Workload Identity の必要性を説明し てもらう • Workload Identity の利用を先行する プロダクト側から、設定方法をヨコ テン
  18. Cloud Security グループ 取組み Gen AI の活用 「AI ファースト」の元、全社的な生成 AI

    の開発支援ツールの利用が活況 Cloud Security グループにおいても、いくつかの支援ツールを利用中 • ツール開発支援 • PRレビュー • GuardDuty Findings 分析 • Cloud Trail 分析 • ツール開発支援 • ガイドライン生成 ( CSPM カイゼン) • ガイドライン生成 • Azure 監査ログ分析 GitHub Copilot Amazon Q Developer pro M365 Copilot, Copilot in Azure
  19. Cloud Security グループ 取組み Tech Blog Azure サブスクリプション の初期セキュリティベスト プラクティスを考える

    CCoE 活動と Google Cloud セキュリティプリ セット環境の提供 KTC クラウドセキュリティ エンジニアのとある一日 LLM アプリケーションのセ キュリティを保護する AI- SPM の取組み