builders.flash

ビジネス x クラウド

AWS Config カスタムルールと Amazon Quick Suite で実現する、セキュリティダッシュボード ~ 開発者 400 人のセキュリティレビューを加速する

2026-01-05 | Author : 角田潤也 (ダイキン工業株式会社)

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

はじめに

こんにちは。ダイキン工業株式会社の角田です。私はダイキン工業という総合空調メーカーにおいて、R&D 部門の AWS 環境の管理や AWS システムのセキュリティ項目をレビューしています。

弊社の R&D 部門では、 AWS を利用して

旧来のオンプレミスベースの開発から AWS ベースの開発への切り替え
新規サービスの展開

が急激に進んでいます。規模で言うと、400 人以上の開発者が、150 個以上の AWS アカウントを利用しています。

開発したシステムではセキュリティレビューが不可欠ですが、レビューの現場では以下の課題が発生していました。

社内の有識者しかセキュリティレビューできないため、有識者への相談件数が爆発する
セキュリティレビューの負荷が高い為、チェックをシステムのリリース前の 1 回しか行っていない

本記事では、上記の課題の解決のために、AWS 上にセキュリティダッシュボードを作成し、社内に普及させていった事例を紹介します。

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

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

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

今すぐ登録 »

課題 1 :

社内の有識者しかセキュリティレビューできないため、有識者への相談件数が爆発する

課題が発生する背景 :

有識者の知見 (オンプレミス知識や社内特有の暗黙知) がないと、社内のセキュリティチェックリストが読めないから

弊社では、IT システムに対するセキュリティ項目をレビューする上では、全社 IT 部門が作成したチェックリスト (Excel 形式) に準拠して行う必要があります。このチェックリストを社内有識者が用いることで、十分にレビューすることが出来ます。

一方、例えば若手社員で、新卒時点から AWS 上でのシステム開発にのみ従事してきた方の視点でチェックリストを見た場合、以下の記述が問題となります。

問題となる記述の例

分かりづらい記述	記述の概要
オンプレミス前提の抽象的な記述	AWS 環境での場合に読み替える手間が発生する書き方。結果として、読み替えの際の「勘違い」「よくわからずベンダーに丸投げ」を引き起こす。
社内の有識者でないとわからない記述	社内で蓄積された、システム開発する上での暗黙知 (不文律・慣例) を前提とした記載がある。初学者が読むと行間を補完できない。

有識者しかレビューできないと、有識者への相談件数が爆発する

上記基準の施行当初は、弊社内での AWS 利用が試験的・小規模なものでした。このため、有識者しかレビューできないことは大きな問題にならず、適切なセキュリティレビューの下でリリースされていました。

上記取り組みが成果を上げたことで、社内で AWS 利用の有用性が周知され、本格的な取り組みが始まりました。具体的には、社内人材育成制度「ダイキン情報技術大学」で若手 IT 人材を育成し、修了生を IT 関係の部署だけでなくIT と縁がない部署にも展開することで、社内の様々な場面で AWS を用いて IT システム開発が行われるようになりました。

しかし、その副作用として、様々な部署から有識者に対する「基準が分かりづらい」という相談が増加し、有識者側で対応しきれない ( = レビュー漏れが起こってしまう) 状況になってしまいました。

解決手段 1 :

有識者の知見 (オンプレミス知識や有識者特有の暗黙知) を落とし込んだ改訂版チェックリストである「AWS 版チェックリスト」を作り、有識者への相談件数を削減する

改良前後のチェックリスト項目の一例を、図に示します。

「AWS版チェックリスト」の変更方針

上記に示したような変更は、以下の方針に基づき行いました。

意図	変更内容
対象読者となる若手社員が、勘違いしやすい記述を排除したい\|	従来リストになかった詳細情報を、すべてのチェック項目に追記した。具体的な AWS サービス名 AWS サービス毎に実施すべき設定設定意図
リスト作成者が、リスト更新コストを最小限に抑えたい	対象を社内で利用頻度の高い AWS 主要サービスに限定した。（具体的なサービス名は図を参照)
誰でも一定の基準で対応できるようにしたい (従来リストのような、有識者毎でも解釈がばらつくような記述をなくしたい)	従来のように社内担当者 1 名 + IT ベンダーでリスト作成する体制を改め、組織横断でリスト作成チームを結成。弊社 R&D 部門の有識者を集め、記述が適切かを話し合う元々のリストを作成した全社 IT 部門と、改訂版リストの意図がずれていないかを話し合う AWS の伴走支援を活用し、チェックリストのレビューを頂く

「AWS 版チェックリスト」を社内に普及させる道のり

「AWS 版チェックリスト」は当初、弊社 R&D 部門の有志が集って作成し、 R&D 部門内に閉じて独自ルールとして運用していました。

しかし、ルールを運用する中で、R&D 部門に閉じることの弊害が出てきました。具体的には、R&D 部門で開発したシステムを事業部に移管する際、改めて旧基準で評価が必要となってしまう問題が発生しました。

この状況を解決すべく、R&D 部門は全社 IT 部門と連携して、「AWS 版チェックリスト」の全社基準化プロジェクトを立ち上げました。具体的には、以下の順序で進めていきました。

実施施策と概要

実施施策	施策概要
R&D 部門と全社 IT 部門で、基準 (AWS 版チェックリスト) のあり方を再確認する	前述の意図を踏まえず「AWS 版チェックリスト」を見ると、旧リストに比べ分量 ( = 利用者負担) が増えたように見えてしまう。このため、前述の意図を全社 IT 部門に伝え、少なくとも R&D 部門内では意図の理解が得られていることを説明した。
実案件で評価する	すでにリストを展開していたR&D部門に対し、いくつかのシステムを対象にレビュー実施結果を収集した。レビュー実施に当たっては、テーマ担当者（システム開発担当者）から見て読み間違いが起きないか・読みづらくないかを評価した。
リリース後も、年 1 度の改訂版をリリースする	開発者の声や AWS 側の更新を、リストに反映する

課題 2

セキュリティレビューの負荷が高い為、チェックをシステムのリリース前の 1 回しか行っていない

PoC 中のシステムやリリース後のシステムに対してレビューするかは、開発チームに委ねられている状況でした。このため、PoC 中のシステムやリリース後のシステムが脆弱になってしまう懸念がありました。

課題が発生する背景

レビューが自動化されておらず、AWS 上のリソース設定を手動で確認する必要がある為、時間がかかる

課題 1 の解決段階で、全社基準が整備され、多くの開発者が自身のシステムを手動でセルフチェックできるようになりました。しかし、R&D 部門内の開発現場からは、依然として以下のような不満が聞こえてくる状況でした。

開発現場の不満

不満	備考
毎回のセキュリティレビュー (社内ルールで定められたもの) の負荷が、依然として大きい	一度のレビューに最大で 2 週間かかる
システムリリース前以外のタイミングでもセキュリティレビューを受ける必要があることは分かっているが、負荷が大きいため行えない	本来であれば、月次ミーティング毎や、システムへの機能追加毎に行い、インシデントのリスクを低減したい

考慮すべきセキュリティレビュー体制

上記のような開発の実態を反映して、全社ルールでも、チェックのタイミングは以下のような取り決めになっていました。

システムのリリース前のチェックは義務付けている (チェックを通さないとシステムがリリースできない)
それ以外のチェックは任意 (努力義務　システム開発者が必要と思ったタイミングでチェック)

理想的にはシステムのリリース前以外にも、例えば月次ミーティング毎にセキュリティ項目をレビューしたいものです。しかし、これを手動チェックで行ってしまうと、開発の俊敏性が大きく損なわれてしまいます。

このため、AWS 開発を阻害しない、以下のようなセキュリティレビュー体制が必要となります。

利用規模を拡大しても、十分なセキュリティレビューが行われる
セキュリティレビューが、AWS 利用拡大におけるボトルネックにならない

解決手段 2 : レビューを自動化し、レビュー結果をダッシュボード上に表示することで、レビュー負荷を軽減した

ダッシュボード上では図のように評価結果が表示され、アカウントやリージョンの移動をワンクリックで行えるようになっています。

採用した AWS サービス

構築時点で定めた要件と、要件を実現するために採用した AWS サービスは、それぞれ以下です。

実現したい要件	AWS サービス
1: 従来手動で行っていたレビューが、自動で (機械的に) 行われる	AWS Config カスタムルール
2: 開発者自身の利用する各アカウント・各リージョンの情報が集約される	AWS Security Hub CSPM / Amazon Security Lake
3: 開発者自身の利用していないアカウントの情報は表示しない (※)	Amazon Athena (クエリ)
4: 開発者自身がいつでも結果を閲覧できる、わかりやすい画面が用意されている	Amazon Quick Suite (結果表示)

※ : この要件を満たす必要があった為、AWS Config 内の集約表示の仕組みとして最もメジャーな「Config アグリゲータ」を敢えて採用しない決定をしました。この機能はワンクリックで設定できる非常に便利なものですが、 AWS Organizations の管理者向けに設計されているため、AWS Organizations 全体 (= R&D 部門の全アカウント) の結果が表示されてしまいます。

アーキテクチャ

上記サービスを組み合わせたアーキテクチャを以下に示します。アーキテクチャを設計する上では、AWS の公式ブログ「How to visualize Amazon Security Lake findings with Amazon QuickSight」が大いに参考になりました。

AWS 公式ブログ「How to visualize Amazon Security Lake findings with Amazon QuickSight」

開発者自らでセキュリティレビューが可能に

このダッシュボードを社内に導入することで、以下のように、開発者自らが (有識者の手を借りずに) ある程度のセキュリティレビューが可能になることが見込まれます。

※PoC 中のシステムやリリース後のシステムに対するレビュー義務付けについては、現段階では行っていません。現段階ではツールを渡し導入支援するにとどめ、実施するかは自主的な取り組みに任せています。

「AWS Config カスタムルール」による、AWS上のリソースがチェックリスト準拠かの自動チェック

レビュー自動化には、まず、AWS の各アカウント上のリソースがセキュリティ基準を満たしているかを自動チェックする必要があります。これを実現するため、AWS サービス「AWS Config」内の機能「AWS Config カスタムルール」を採用しました。

AWS には「AWS Config」という、リソース設定を JSON 形式で格納し、望ましい「Key-Value ペア」のルールに準拠しているかどうかを判定してくれるサービスがあります。AWS Config をアカウント上に設定しただけでは、まだルールは設定されておらず、個々にルールを追加する必要があります。追加するルールとしては、AWS を運用する上でのベストプラクティスを AWS 自身がまとめた AWS Foundational Security Best Practices (FSBP) 標準があります。このルールは AWS Security Hub Cloud Security Posture Management (CSPM) というサービスを用いてワンボタンで有効化できます。弊社でも当初はこの方法で FSBP の有効化を行いました。

これに加え、社内固有の条件を含むルール (例 : インターネットからの接続を受け付ける社内向け Web API については、接続元 IP アドレスを社内のものに制限する) については、AWS Config のカスタムルールを定義しました。結果、「AWS 版チェックリスト」における AWS インフラ周りの項目については、すべての項目を自動化できました。

自動化していない項目

一方、「AWS 版チェックリスト」内の以下の項目については、自動化していません。

ルールのカテゴリー	自動化していない理由
アプリケーションコード周り (4 項目)	AWS Config ではアプリケーションコードを読むことは不可能 (Amazon Inspector などでのアプローチが必要)
運用体制周り (10 項目)	敢えて行わない (開発者・開発チーム内の知識や意識を問う設問の為、自動化してはいけない)

カスタムルールを定義する上での注意点：2 つのカスタムルールを使い分ける必要がある

カスタムルールにて、準拠/非準拠を判定するためのロジックを定義するには、以下の 2 つの方法が用意されています。（詳細は公式ドキュメントを参照ください）

ルール名	定義方法	メリット	デメリット
AWS Config Custom Policy Rules	Guard という Policy-as-code 専用言語を用いて、ロジックを定義する	定義が簡潔にでき、保守しやすい	定義の自由度が低い (後述の「エッジケース」で詳細説明)
AWS Config Custom Lambda Rules	Lambda 関数にて、ロジックを定義する	定義の自由度が高い	定義が複雑になりがちで、保守しづらい

AWS Config Custom Policy Rules の利用

前述の特徴から、保守しやすさを鑑み、弊社では原則 AWS Config Custom Policy Rules を用いてロジックを定義することにしました。ここでは AWS Config Custom Policy Rules の簡単な例として、ALB リスナーで待ち受けるプロトコルとして、暗号化していないプロトコル(ここでは HTTP)を禁止する例を示します。AWS Config には、以下のように各リソースの設定が JSON 形式で格納されています。

json

{
  "resourceType": "AWS::ElasticLoadBalancingV2::Listener",
  "configuration": {
    "Protocol": "HTTP",
    ...
  }
  ...
}

ロジックの定義

これに対し AWS Config Custom Policy Rules では、下のように拒否リスト形式でロジックを定義することが出来ます。

json

configuration.Protocol != "HTTP"

AWS Config Custom Lambda Rules の利用

「AWS Config カスタムルール」を構築していると、AWS Config Custom Policy Rules では記述できないようなケースに行き当たることがあります。このような場合には、AWS Config Custom Lambda Rules での記述が必要となります。

前述のように、AWS Config Custom Policy Rules は、以下のような制約を設けることで、シンプルなカスタムルール定義を実現しています。

AWS Config 上に JSON 形式で格納された単一リソース設定を対象とする
Guard を用いて定義されたロジックで評価する

AWS Config Custom Policy Rules では記述できないケース

この制約は、以下のようなケースで問題になります。

AWS Config Custom Policy Rules では記述できないケース	具体例
AWS Config上にJSON 形式で格納されていない情報について追加取得するような処理はできない	リソース自体が AWS Config に対応していないリソース自体は AWS Config に対応しているが、Config の JSON に記載されない設定がある
Guard 記法では表現できないロジックは定義できない	複雑な文字列処理・算術処理が必要なロジック
複数リソース設定にまたがるロジックを定義できない	社内向け Web ページについて、アクセス元を社内ユーザーに制限するために、接続元 IP アドレス制限(Amazon EC2 Security Group や AWS WAF で設定) 多要素認証 (Cognito で設定) を行っているか ? 上記例では、少なくとも「Amazon EC2 Security Group」「AWS WAF」「Amazon Cognito」の確認が必要となる

AWS Config Custom Lambda Rules でルールを作成

弊社では、この制約を突破したいケースに限って AWS Config Custom Lambda Rules でルールを作成しています。

この場合、ロジックは Lambda 関数で利用できる任意のプログラミング言語で記述できます。ロジックを運用 (特に、テスト) する上での注意点も、一般的なアプリケーションのそれに準じて行う必要があります。

ロジックを運用する上での助けになるツールとして、弊社では AWS Rule Development Kit (RDK) を採用しています。これは AWS Config Custom Lambda Rules の作成に特化したツールです。プログラミング言語に Python しか利用できないなどの制約こそありますが、ロジック定義やテスト設計を強力に支援してくれます。
(他に、Lambda 内で OPA などの Policy-as-code 専用言語を用いることで、記述を簡潔にするアプローチもありますが、今回は使用していません)

Amazon Security Lake + Amazon Quick Suite で作る、開発者全体に公開可能なダッシュボード

「AWS Config カスタムルール」を整備するだけでは、開発者が実業務で自動チェック結果を確認する上で、以下のような障壁が問題となります。

AWS Config カスタムルールを実業務で運用する際の障壁	備考
開発者自身の利用する各アカウントにそれぞれログインし、各リージョンの評価結果 (準拠/非準拠) を確認することが手間	社内ではマルチアカウント (本番 / ステージング / 開発毎などでアカウントを分ける) が奨励されているため、影響範囲が大きい ap-northeast-1 リージョンしか意識していないユーザーでも、us-east-1 リージョン上にしか構築できないリソース (Amazon CloudFront など) を使っているケースが多く、チェック漏れにつながる
開発者自身で確認結果をまとめて、上長などに報告することが手間	まとめる際に転記漏れが起こりうる

自動チェック結果表示ダッシュボードの構築

このため、各アカウント・リージョンでの自動チェック結果を集約表示するダッシュボードを構築しました。ダッシュボードを作成する上では、シンプルさと深掘りしやすさを両立することを意識しました。

シンプルさ：非準拠リソースが一覧表示され、全体像を一望できる
AWS マネージメントコンソール上の表示では、この要件を満たせなかった
深掘りしやすさ：各リソースの詳細な設定状況を深掘りし、修正できる
AWS マネージメントコンソール上には、深掘りを実現する機能が多くあるため、各機能へのリンクをダッシュボード上に貼るのみでよいと判断した

深掘りしやすさを実現する為のTips： Quick Suite 上のダッシュボードから、AWS マネージメントコンソール上の各機能へのリンクを貼る方法

通常、AWS マネージメントコンソール上の各機能にアクセスするには、以下の手順が必要です。

AWS ログインコンソールや、 AWS IAM Identity Center の Access Portal から、各 AWS アカウントにログインする
所定のリージョンに変更する
マネージメントコンソール上でリンクをたどり、所定のページにたどり着く

各機能へのリンク貼付

上記の操作を省略する為に、ダッシュボードに各機能へのリンクを貼り付けることにしました。具体的には、AWS IAM Identity Center の Access Portal の 1 機能「ショートカットリンク作成機能」を活用して、ダッシュボード→ AWS マネージメントコンソールへのリンクを実現しました。この機能は、以下の形式のリンクを通して利用することが出来ます。

ショートカットリンク作成機能

xml

https://[your_subdomain].awsapps.com/start/#/console?account_id=[account_ID]&role_name=[permission_set_name]&destination=[destination_URL]

リンクアクセス時に行われること

AWS IAM Identity Center に登録されたユーザーが上記リンクにアクセスした際、以下が自動的に行われます。

https://[your_subdomain].awsapps.com で設定した自社の AWS IAM Identity Center にログインしていない場合、ログインする（ログイン画面にリダイレクトする）
[account_ID] の AWS アカウントに、[permission_set_name] のロールでログインする
[destination_URL] の AWS マネージメントコンソールページに遷移する
[destination_URL] では、 AWS リージョンの指定と、どのサービスのどのページかの指定がされている

各処理は AWS IAM Identity Center にて行われるため、利用者側の操作の簡便さとセキュアさを両立することが出来ます。

今回は上記のリンクを Quick Suite 内に埋め込むことで、ダッシュボード上の各リソースをクリックするだけで、AWS Config マネージメントコンソール上の詳細情報へアクセス可能にしました。

AWS Config のマネージメントコンソールは、前述の通り一覧性に難があるものの、各リソースの個別ページに到達さえすれば、以下のようにリソースの設定状況深堀りに便利な機能が提供されています。

* 各リソースの詳細な設定状況を表示する
* 「リソースタイムライン」で、リソースがいつ設定変更されたかを確認する
* 「リソースの管理」で、各サービスのページに遷移する
* ルールに紐づいた修正スクリプトを実行できる

これらを基に、開発者自らが非準拠リソースを認識 → 修正できます。

このように、内製すべき部分と AWS 自体の機能で実現できる部分をうまく組み合わせることで、ダッシュボードを工数少なく開発できました。今後もAWS が続々と発表しているセキュリティ関係のサービスと連携し、ダッシュボードの機能強化を行っていこうと考えています。

ダッシュボードの普及活動に不可欠だったこと

今回の取り組みは、普及活動を行い社内のセキュリティリスク低減まで達成しないと、効果があったとは言えません。単に当方で定めた当初目標を満たしたダッシュボードを構築・展開するだけではなく、以下のような粘り強い取り組みが必要になります。

取り組み 1：開発者とダッシュボードを一緒に確認し、非準拠項目を二人三脚で対応する
取り組み 2：利用者から得られたフィードバックを基に、ダッシュボードを改良する

取り組み 1：開発者とダッシュボードを一緒に確認し、非準拠項目を二人三脚で対応する

残念なことに、管理者がダッシュボードを用意して URL を公開しただけでセルフレビューしてくれる開発者は、滅多にいません。このため、当方から各開発者に対し、以下のような取り組みを継続的に行っています。

社内チャットツールにて情報発信する
システムリリース前での手動チェック (社内ルールで定められたもの) の際に、自動チェック可能な項目についてはダッシュボードを併用して説明し、利用方法も紹介する
その他社内イベント (例 : 外部イベント参加後の報告会) にて、ダッシュボードを宣伝する

取り組み 2：利用者から得られたフィードバックに基づき、ダッシュボードを改良する

直近で行った改良は以下です。

利用者から得られたフィードバック	行った改良
ダッシュボード上で非準拠リソースを発見した後、該当リソースの設定を変更するまでの画面遷移が手間	(前述の) AWS Config のマネージメントコンソールへの画面遷移機能
AWS から EC2 や Lambda の EoL に関する連絡が来たが、どのリソースが対象なのかの調査が手間	EoL 済みや EoL が近い OS・ランタイムを使用しているリソースの抽出機能

デプロイの自動化

改良箇所を利用者のダッシュボードにいち早く反映するため、システムのデプロイは可能な限り自動化しています。

AWS CloudFormation StackSets による、各アカウントへのカスタムルールの配布
AWS CDK による、ダッシュボードの更新

こういった自動化が行いやすいことも、ダッシュボードを AWS 上に構築することによる利点として大きいと、日々実感しています。

成果 1　: R&D 部門の開発者 100 人に閲覧可能にし、インシデントを未然に防ぐ成果を上げた

ダッシュボードは R&D 部門の開発者 100 人 (社内開発者に加え、開発に協力いただいているベンダーの方も含む) に閲覧可能にしています。開発者からも以下のような肯定的なフィードバックを得られています。

規模が大きいシステムでも 1 時間程度で非準拠設定を把握できた
把握した非準拠設定に対応する工数も削減された

今後は今年度中をめどに R&D 部門の 400 人以上の開発者全員が閲覧可能な状態とする予定です。

また、ダッシュボードを通してインシデントを未然に防いだ事例もありました。ひとつ例を挙げると、こちらのスクリーンショットのように、本来ブロックすべき通信を許可していた設定ミスを自動検知しています。

この事例では利用者側で記述したチェックリストには問題ないと記載いただいたものの、ダッシュボードを用いて実リソースを確認すると実は問題ある状態になっていたという状態でした。こういった事例から得られた教訓は以下です。

人手での手動チェックでは、AWS の各サービスの細かい設定ミスを見落とす可能性が排除できない
チェック手順が煩雑 (チェックリストを隅々まで読み内容把握 → 全 AWS アカウント・全リージョンのマネジメントコンソールを調査→誤設定か議論)
本ダッシュボードでの自動チェックを活用することで、各設定を容易に一望できる
ダッシュボードを見ながら、即議論できる

成果 2: セキュリティチェックだけでなく、アカウント内のリソースやアカウントそのものの棚卸も行えた

ダッシュボードでは、利用者がアクセスできるすべてのアカウント・リージョンの情報を表示してくれます。このため、現在運用しているシステムの脆弱な設定だけでなく、過去構築したプロトタイプやテスト用のリソースを消し忘れたものを発見できます。

このようなリソース (場合によってはアカウント自体) を逐次削除するよう呼びかけることで、インシデントのリスク低減と、 AWS 利用コストの削減を実現しました。

まとめ

本記事では、ダイキン工業株式会社 R&D 部門における AWS 環境のセキュリティレビューを加速する、セキュリティダッシュボードについて紹介しました。

自動化の前段階として、オンプレミス前提の抽象的なセキュリティ基準を AWS ネイティブな具体的基準へと改良し、全社基準として公開しました
AWS Config カスタムルールによる自動チェックと、Amazon Quick Suite による直感的なダッシュボードでの可視化を実現しました
普及活動では開発者との連携やフィードバックを重視し、ダッシュボードの継続的な改良と自動化を推進しました
結果として、開発者の負担軽減やインシデント未然防止、コスト削減などの成果を得ることができました

今後も AWS の新サービスと連携し、さらなる機能強化を目指していきます。

筆者プロフィール

角田潤也 (つのだじゅんや)

ダイキン工業株式会社で、R&D 部門の AWS 環境の管理や AWS システムのセキュリティ項目をレビューしています。2019 年に新卒入社し、「ダイキン情報技術大学」の 2 期生として AI・データ活用について学んできました。

趣味はラーメン屋探しです。