builders.flash

AWS Service Catalog 製品による社内セキュリティルールのダッシュボード構築と運用ノウハウ ~ みずほ銀行が AWS CDK で実装したマルチアカウント管理の仕組み第 4 回

2026-04-02 | Author : 志田淳弥 (株式会社みずほ銀行)

無料クーポン特典の詳細 »

はじめに

builders.flash 読者の皆さん、こんにちは ! 株式会社みずほ銀行の志田です。（※2026 年 4 月 1 日付で、みずほリサーチ＆テクノロジーズ株式会社は株式会社みずほ銀行へ統合されました。）

当社では AWS Cloud Development Kit (AWS CDK) を活用して、AWS Control Tower 環境におけるマルチアカウント環境の管理基盤を構築・運用しています。

これまでの連載では、AWS Service Catalog を使ったセルフサービス型機能の提供や、AWS Step Functions を活用したアカウント発行処理などについて解説してきました。

今回は AWS Service Catalog 製品による社内セキュリティルールに則ったダッシュボード構築について、具体的な実装例を含めてご紹介します。

第1回：AWS Service Catalog を使ったセルフサービス型機能の提供
第2回：Step Functions を使ったアカウント発行自動化
第3回：組織単位ごとのガバナンス戦略！AWS Service Catalog 製品のセキュリティ運用と CI/CD パイプライン実践例
第4回：AWS Service Catalog製品による社内セキュリティルールのダッシュボード構築と運用ノウハウ (今回)

今後も連載を予定していますので、そちらもお楽しみに！

X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

今すぐ登録 »

本記事で解説する内容

当社では、クラウド利用に関するセキュリティポリシーおよびガバナンス基準を整備しています。

一方で、準拠状況の確認や監査対応にあたり、スプレッドシートのチェックリストや証跡収集など手動運用に伴う過大な工数が課題でした。

本記事では AWS Service Catalog を活用し、セキュリティダッシュボードを全アカウントへ配布する実践アプローチを解説します。

とくに、AWS Security Hub CSPM の Custom Insight の配布や監査・制御系リソースの自動展開について、コード例を用いた実装事例をご紹介します。

社内セキュリティルールの標準化と自動配布

当社では、サイバーセキュリティチーム（管理者側）がCIS Benchmarksなどの国際的なセキュリティ基準をベースに、社内ポリシーに準拠したクラウド設定チェックリストを策定しています。

このチェックリストは、AWSなどの各クラウドプラットフォームの特性に合わせた評価基準を設定し、組織全体での統一的なセキュリティ管理を目指しています。

プラットフォーム利用者側は、このチェックリストに基づき、自身のアカウントやリソースがポリシーに準拠しているかを確認・報告する必要があります。しかし、このルールを守るための確認作業が、現場の大きな負担となっていました。

この課題と解決策を、実際の運用フローに沿ってご説明します。

【Before】手動確認とスクショ収集の「泥臭い」現実

従来のチェックリスト運用の実態として、セキュリティを担保するために利用者と管理者は以下のような非効率なループに陥っていました。

「画面」を巡回する手間
利用者は AWS マネジメントコンソールを開き、AWS Identity and Access Management (IAM)、Amazon Simple Storage Service (Amazon S3)、Amazon VPC セキュリティグループなどのチェック項目ごとに異なる画面で設定値を目視確認しなければなりませんでした。
「スクリーンショット」撮影という本質外の作業
確認した設定が正しいことを証明するために、スクリーンショット取得の作業が発生していました。「エビデンスを残す」という目的のためだけに、膨大な枚数の画像をスプレッドシートに貼り付ける作業は利用者の時間を大きく奪うものでした。
メールやファイルによる「やり取りの往復」
作成した資料は管理者へ提出されますが、もし不備があれば「再提出依頼→再撮影→再送付」というやり取りが発生します。このコミュニケーションコストも無視できない問題でした。

【After】Custom Insight 導入による「1画面」への集約

この状況を打破するため、Custom Insight を導入し、運用を刷新しました。

「1 画面」にすべてを集約
社内ポリシーに基づくチェック結果は、Custom Insight の 1 つの画面に集約・可視化されます。
利用者と管理者が「同じダッシュボード」を見る
利用者も管理者も同じダッシュボードを見るだけで状況を把握できます。
メールでエビデンスを送るのではなく、ダッシュボードを見て NG になっている項目があれば修正をするという、シンプルなアクションだけで常に最新のセキュリティ状態が保たれるようになりました。

AWS Service Catalog による「Custom Insight の自動配布」

さらに、AWS Service Catalog を活用して、Custom Insight の自動配布を実現しました。

Custom Insight の AWS Service Catalog 製品化プロセス

社内のセキュリティ基準である「クラウド設定チェックリスト」を、どのようにしてコードへ落とし込み、製品としてパッケージングしたか。その実践プロセスを 3 つのステップで解説します。

1. 概念実証：目視チェックからの脱却

最初に取り組んだのは、「人間による目視チェック (Checklist）」から「システムによる自動フィルタリング (Insight）」へのシフトです。

従来の手順では、利用者が IAM、Amazon S3、Amazon VPC セキュリティグループなどのチェック項目ごとに異なる画面を 1 つずつ開き、設定値を目視確認 & エビデンスとしてスクリーンショットを保存していました。しかし、エンジニアリングの視点でこの作業を分解すると、私たちが探しているのは「正しい状態」ではなく、「例外的な状態 (違反）」であることに気づきます。

そこで、「エビデンスを撮って回る」定常的な巡回業務を廃止しました。日常的な監視は違反検知時の「自動通知」に任せ、ダッシュボード (Insight) はリリース判定や監査対応など、特定のタイミングで「現在、違反がないこと」を証明するために利用します。これにより、 「リストが 0 であれば準拠 (合格）」 という、シンプルな運用手法が確立されました。

2. 設計 : クラウド設定チェックリストと Custom Insight の対応

次に、チェックリストの各項目を具体的な技術仕様 (フィルタリングルール) へ落とし込む設計を行いました。

ここで重要だったのは、「適合条件 (~ であること）」から「違反条件 (~ でないもの）」へのロジック変換です。Custom Insight は「条件に合致する検出結果 (Findings）」を表示する機能であるため、チェックリストの要件を「違反条件」に書き換える必要があります。

具体的には、以下のようなロジック変換を行いました。

ロジック変換のマッピング例

チェックリスト項目	Custom Insight 抽出条件	判定ロジック
No.xx EBS ボリュームを「暗号化していること」	[条件] EBSボリュームが暗号化されていない [結果] 未暗号化ボリュームの一覧が表示される	検出結果がある = 不合格
No.xx S3バケットが「インターネット上に公開されていないこと」	[条件] S3バケットの「パブリックアクセスブロック」設定が無効 (OFF) になっている [結果] 外部公開されているバケットの一覧が表示される	検出結果がある = 不合格

この変換作業を通じて、具体的な Filters (GeneratorId や RecordState など) のセットとして定義しました。

3. 実装と配布 : AWS CDK × AWS Service Catalog による製品化

設計した Filters の定義を、AWS CDK を用いて実装して AWS Service Catalog 経由で全アカウントへ展開することにしました。

AWS CDK による実装

複数の Custom Insight をコンソール上で 1 つずつ手動設定するのは、作業数が増えるだけでなく、操作ミスや設定漏れのようなヒューマンエラーの危険があります。

そこで、AWS CDK を用いてコードで定義・生成するアプローチを採用しました。

実装のポイントは、「チェックリストの定義 (前項のマッピング情報）」と「リソース作成のロジック」を分離した点です。この実装により、新しいルールを追加する際もチェックリストの定義に1行追加するだけで即座に実装へ反映できる保守性の高い運用フローを確立しました。

AWS Service Catalog を活用したテナントアカウントへの展開

AWS CDK によって生成された AWS CloudFormation テンプレートは、AWS Service Catalog の「製品」として登録して、各テナントアカウントに展開しました。（詳細は第 3 回記事「組織単位ごとのガバナンス戦略」を参照）

第 3 回記事「組織単位ごとのガバナンス戦略」

監査・制御系リソースの自動展開

Custom Insight によるチェックリスト準拠状況の可視化に加え、チェックリストに対応したセキュリティ設定を自動適用するリソースも併せて展開しています。

展開している監査・制御リソース例

チェックリスト項目	自動展開リソース
Amazon VPC セキュリティグループの公開設定	Amazon VPC セキュリティグループのフルオープンルールの検知・自動修復
AWS CloudTrail ログのアラーム設定	AWS CloudTrail ログ監視とアラーム
アクセス元 IP 制限	AWS アカウントへの IP 制限

このように、「Custom Insight による監視」と「制御リソースによるガードレール」という二重の仕組みにより、人手に頼ることなくセキュリティ基準の確実な遵守を実現しています。

AWS Security Hub CSPM の集約と「共通の物差し」の展開

AWS Security Hub CSPM を効果的に運用するポイントは、次の二点です。

検出データを一箇所に集めること
評価基準 (カスタムインサイト) を関係者全員が共有すること

当社では管理者が全社の状況を把握するだけでなく、各テナントアカウントの管理者も自律的にリスクに気づけるように以下の構成をとっています。

1. データの集約 (AWS Organizations 連携)

AWS Organizations 連携により、全テナントアカウントの検出結果を監査 (Audit) アカウントへ集約しています。これにより、監査アカウントの管理者は全テナントアカウントのセキュリティ状況をリアルタイムで確認できます。

2. 評価基準の配布 (Custom Insight の展開)

Custom Insight (ダッシュボード定義) を、AWS Service Catalog を通じて全アカウントへ配布することで、管理者と利用者が同じダッシュボードを見て準拠状況を確認できます。

従来は監査のタイミングでしか準拠状況を把握できませんでしたが、Custom Insight により リアルタイムで準拠状況を確認できるようになりました。

利用者のメリット : 自アカウントの Insight を確認し、件数が「0」になるよう自律的に修正できます。
管理者のメリット : 全アカウントの準拠状況を横断的に確認し、「No. 10 の項目が検知されています」と共通番号で具体的な指示が出せます。

3. OU 特性に合わせた展開戦略

この「共通の物差し」である Custom Insight を配布・更新する際、第 3 回記事で解説したフルサービス/セルフサービス戦略を活用しています。

アカウント種別	更新方式	狙い
テナントの本番/開発環境	セルフサービス (任意更新)	本番環境を持つテナントアカウント管理者は、業務都合に合わせて任意タイミングでダッシュボード製品を更新します。
上記以外	フルサービス (自動更新)	管理者が自動的に最新版を適用します。

チェックリストが改訂された際も、この仕組みにより、利用側の現場の混乱を避けながら組織全体のセキュリティ基準を引き上げることが可能になっています。

AWS CDK による IaC 実装例

ここからは当社のソースコードから一部を抜粋して、Custom Insight の具体的な実装方法を解説します。

#	ライブラリ	バージョン
1	AWS CDK CLI	2.1033.0
2	AWS CDK ライブラリ	2.232.1
3	TypeScript	5.9.3

1. チェックリストの定義と型設計

まずは、セキュリティチェックリストの各項目をコードで管理するための定義を行います。 Custom Insight を構成する要素を InsightDefinition インターフェイスとして型定義し、設定ファイルとして切り出します。コード例は以下の通りです。

typescript

export interface InsightDefinition {
  id: string;
  name: string;
  filters: {
    generatorId?: { value: string; comparison: string }[];
    complianceStatus?: { value: string; comparison: string }[];
  };
}

export const InsightSettings: InsightDefinition[] = [
  {
    id: "No_xx_EBS_Encryption",
    name: "No.xx EBSボリュームを暗号化していること",
    filters: {
      // Security Hub CSPMのコントロールID(検査項目)でフィルタリング
      generatorId: [
        // Control ID: EC2.3 - 接続状態にあるEBSボリュームが暗号化されているかどうかをチェックする。
        { value: "security-control/EC2.3", comparison: "EQUALS" }
      ],
    },
  },
  {
    id: "No_xx_S3_PublicAccessBlock",
    name: "No.xx S3バケットがインターネット上に公開されていないこと",
    filters: {
      generatorId: [
        // Control ID: S3.8 - Amazon S3汎用バケットがバケットレベルでパブリックアクセスをブロックしているかどうかをチェックする。
        { value: "security-control/S3.8", comparison: "EQUALS" },
      ],
    },
  },
  // ... 他のチェックリスト項目
];

2. Custom Insight の実装

定義した設定ファイルを読み込み、ループ処理によって Custom Insight リソースを一括生成します。これにより、チェックリスト項目が増減した場合でも、コードロジックを変更することなく設定ファイルの修正のみで対応が可能になります。コード例は以下の通りです。

typescript

import { Construct } from "constructs";
// インサイトの定義をインポート
import { InsightSettings } from "./insightSettings";

export class SecurityHubInsights extends Construct {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // インサイト定義の配列をループ処理で一括作成
    for (const insight of InsightSettings) {
      new securityhub.CfnInsight(this, insight.id, {
        name: insight.name,
        filters: {
          ...insight.filters,
          workflowStatus: [
            { value: "NEW", comparison: "EQUALS" },
            { value: "NOTIFIED", comparison: "EQUALS" },
          ],
          recordState: [{ value: "ACTIVE", comparison: "EQUALS" }],
        },
        groupByAttribute: "AwsAccountName",
      });
    }

    // Custom Insight 結果通知用のリソース定義（詳細は省略）
    // ...
  }
}

実装のポイント

一括生成 : InsightSettings 配列をループし、定義ごとに insight を作成します。
共通フィルタの適用 : すべてのインサイトに対して、以下の状態フィルタを付与します。
- workflowStatus : NEW または NOTIFIED (解決済みの「SUPPRESSED」ステータスは除外)
- recordState : ACTIVE (アーカイブ済みを除外)
- groupByAttribute: デフォルトで AWS アカウント名によるグループ化を適用します。

3. AWS Service Catalog 製品への統合と配布

これまで実装してきた「Custom Insight」や「監査・制御リソース」などの各機能を、ProductStack を用いて 1つの AWS Service Catalog 製品としてパッケージングします。

その後、製品をポートフォリオに登録し AWS Organizations 全体へ共有することで、各アカウントの管理者がコンソールから利用できる状態にします。

※ ProductStack 内で自作 Construct を呼び出す実装や、ポートフォリオの共有設定に関する具体的なコード例については本稿では割愛します。詳細については Baseline Environment on AWS (BLEA) の実装をご覧ください。

利用者として実際に使ってみた感想

現在、私はプラットフォームの提供側ではなく、プラットフォーム上で DX アプリを構築する開発者として本仕組みを日々活用しています。

機能的な効率化以上に強く感じているのは、「セキュリティチェックのプレッシャーから解放された」 という心理的な変化です。

チェック作業の「憂鬱」からの解放

以前は PoC 環境を 1 つ作るだけでも、セキュリティチェックリストと WSマネジメントコンソールの画面を何度も見比べ、「このリソースは大丈夫か」「確認漏れはないか」と 1 つずつ手作業でチェックする必要がありました。PoC を行うたびにこの作業が発生するため、新しい検証への着手が心理的な負担になっていました。

現在は Custom Insight によってチェック作業が大幅に簡略化されたため、こうした煩雑な作業自体が不要になりました。「何かあればアラートが出る」という安心感のおかげで、検証作業への心理的ハードルも大きく下がりました。

おわりに

本記事では、AWS Service Catalog を活用した社内セキュリティルールのダッシュボード構築について、具体的な実装例を解説しました。

最大の成果は、セキュリティ統制を強化しながらも、利用者の利便性を犠牲にしない「統制と自律の両立」を実現できたことです。

利用者と管理者が同じダッシュボードで状況を共有することで、認識のズレや過度な確認作業をなくし、誰もが本来の業務に集中できる環境を実現しました。

この連載を通じて、当社における AWS マルチアカウント管理の実践事例をご紹介してきました。

次回は、Amazon VPC の IP アドレス管理やネットワーク自動化など、引き続き実践的なノウハウをお届けする予定です。お楽しみに !

最後までお読みいただき、ありがとうございました。

参考資料

筆者プロフィール

志田淳弥
株式会社みずほ銀行
デジタル技術開発部アソシエイト

入社以来、AWS を活用したシステム開発やクラウド人材育成、社内共通プラットフォームの構築・運用など、パブリッククラウドの推進に幅広く携わる。現在は社内 DX アプリの推進に従事。その他、〈みずほ〉グループ横断コミュニティ「コクリエ」を運営。

AWS Service Catalog 製品による社内セキュリティルールのダッシュボード構築と運用ノウハウ ~ みずほ銀行が AWS CDK で実装したマルチアカウント管理の仕組み第 4 回

はじめに

builders.flash メールメンバー登録

本記事で解説する内容

社内セキュリティルールの標準化と自動配布

【Before】手動確認とスクショ収集の「泥臭い」現実

【After】Custom Insight 導入による「1画面」への集約

AWS Service Catalog による「Custom Insight の自動配布」

最新ルールが適切な方法で届く仕組み

Custom Insight の AWS Service Catalog 製品化プロセス

1. 概念実証：目視チェックからの脱却

2. 設計 : クラウド設定チェックリストと Custom Insight の対応

ロジック変換のマッピング例

3. 実装と配布 : AWS CDK × AWS Service Catalog による製品化

AWS CDK による実装

AWS Service Catalog を活用したテナントアカウントへの展開

監査・制御系リソースの自動展開

展開している監査・制御リソース例

AWS Security Hub CSPM の集約と「共通の物差し」の展開

1. データの集約 (AWS Organizations 連携)

2. 評価基準の配布 (Custom Insight の展開)

3. OU 特性に合わせた展開戦略

AWS CDK による IaC 実装例

1. チェックリストの定義と型設計

2. Custom Insight の実装

実装のポイント

3. AWS Service Catalog 製品への統合と配布

利用者として実際に使ってみた感想

チェック作業の「憂鬱」からの解放

おわりに

参考資料

筆者プロフィール

学ぶ

リソース

デベロッパー

ヘルプ

AWS Service Catalog 製品による社内セキュリティルールのダッシュボード構築と運用ノウハウ ~ みずほ銀行が AWS CDK で実装したマルチアカウント管理の仕組み 第 4 回

はじめに

builders.flash メールメンバー登録

本記事で解説する内容

社内セキュリティルールの標準化と自動配布

【Before】手動確認とスクショ収集の「泥臭い」現実

【After】Custom Insight 導入による「1画面」への集約

AWS Service Catalog による「Custom Insight の自動配布」

最新ルールが適切な方法で届く仕組み

Custom Insight の AWS Service Catalog 製品化プロセス

1. 概念実証：目視チェックからの脱却

2. 設計 : クラウド設定チェックリストと Custom Insight の対応

ロジック変換のマッピング例

3. 実装と配布 : AWS CDK × AWS Service Catalog による製品化

AWS CDK による実装

AWS Service Catalog を活用したテナントアカウントへの展開

監査・制御系リソースの自動展開

展開している監査・制御リソース例

AWS Security Hub CSPM の集約と「共通の物差し」の展開

1. データの集約 (AWS Organizations 連携)

2. 評価基準の配布 (Custom Insight の展開)

3. OU 特性に合わせた展開戦略

AWS CDK による IaC 実装例

1. チェックリストの定義と型設計

2. Custom Insight の実装

実装のポイント

3. AWS Service Catalog 製品への統合と配布

利用者として実際に使ってみた感想

チェック作業の「憂鬱」からの解放

おわりに

参考資料

筆者プロフィール

学ぶ

リソース

デベロッパー

ヘルプ

AWS Service Catalog 製品による社内セキュリティルールのダッシュボード構築と運用ノウハウ ~ みずほ銀行が AWS CDK で実装したマルチアカウント管理の仕組み第 4 回