ダイキン工業が実践したAWSインフラ運用自動化とPolicy as Code、現場定着のリアル：「ダッシュボードを用意しただけでは開発者は使ってくれない」
クラウド活用が拡大する中、セキュリティや運用ルールの「形骸化」「属人化」に悩む企業も多いだろう。ダイキン工業は、AWSインフラ運用の現場で、従来の抽象的なセキュリティ基準を“Policy as Code”としてコード化し、自動チェックを実現した。新たな運用を1年間続ける中で、どのような成果と課題が生まれたのか。
インフラ運用において、業務の自動化はもはや必須事項となっている。手動作業のままでは効率が悪いだけでなく、手間やミスのせいで重大なインシデントを引き起こしかねないからだ。
2025年の「Cloud Operator Days Tokyo」のプレス向けイベントにおいて、ダイキン工業の角田潤也氏（テクノロジー・イノベーションセンター＜R&D＞ データ活用推進G）は「実践！Policy as Code 〜社内ルール準拠のAWS自動チェックを1年間運用して〜」と題し、同社の「Amazon Web Services」（AWS）環境におけるセキュリティ自動チェックの取り組みについて講演した。
非情報系IT担当者の前に立ちはだかる「オンプレミス前提のルール」
ダイキン工業は1924年に創業した、100年の歴史を持つ総合空調メーカーであり、空調機器と冷媒の両方を手掛けている。従業員は2025年3月31日現在10万人を超え、グローバルに110カ所以上の生産拠点を持つ大規模な事業展開をしている。同社は、若手育成にも積極的で、「ダイキン情報技術大学」という社内学習の仕組みを整えており、それを“修了”した非情報系の新入社員が多数IT部門に配属されているという。
登壇者の角田氏もダイキン情報技術大学を修了した若手エンジニアの一人だ。同氏はダイキン工業のR&D部門で、400人以上のユーザーと150個以上のアカウントを抱える大規模なAWS環境の管理とセキュリティレビューに従事している。
ダイキン工業では会社全体でクラウド上での俊敏な開発を進めているが、そんな中、セキュリティに関するある課題が浮上した。それは、全社IT部門が過去に作成したセキュリティ基準がオンプレミス環境を前提としており、有識者でなければ理解が難しい抽象的な内容だったのだ。このため、「勘違い」や「よく分からずベンダーに丸投げ」といった問題が頻発し、クラウドネイティブな開発環境に適合しないという弊害が生じていた。
問題はもう一つあった。それはセキュリティチェックが手動だったことだ。チェックリストを基に一つ一つチェックするのは時間がかかる。結果として、レビューが実施されるのはリリース前の特定のタイミングだけという状況になっていた。クラウド利用が急増する中、「ダイキン工業では『点』ではなく『面』で継続的にセキュリティ状態を監視する仕組みが強く求められていた」（角田氏）
「Policy as Code」の実践
ダイキン工業はこれらの課題に対し、以下の取り組みを進めた。
AWSネイティブな新セキュリティ基準の制定
R&D部門と本社の有識者が連携し、勘違いしやすい項目を中心に基準を大幅に修正した。具体的なサービス名や設定意図を詳細に記載することで、開発者が内容を「腹落ち」させ、確実に順守できるよう努めた。対象は社内で利用頻度の高いAWS主要サービス「Application Load Balancer」「Amazon CloudFront」「Amazon Elastic Compute Cloud」「Amazon Elastic Container Service」「AWS Lambda」「Amazon Cognito」「Amazon DynamoDB」などに絞り込んだ。
自動チェックの導入とダッシュボードの構築
手動チェックの限界を乗り越えるため、「Policy as Code」、つまりルールを「コード化」し、システムが自動でチェックできるようにすることで、運用の効率化を実現しようと考えた。また、その結果を一目で確認できるダッシュボードを構築することで利便性も向上させた。角田氏によると、AWSには「AWS Config」という、リソース設定をJSON形式で格納し、望ましい「Key-Valueペア」のルールに準拠しているかどうかを判定してくれるサービスがある。これを違反を自動的に検出する仕組みとして使うことにした。
ただ、AWSが提供するFSBP（Foundational Security Best Practices）などのデフォルトルールだけでは社内ルール、特に社内向けアプリケーションのアクセス制限（IPアドレスや多要素認証のAND／OR条件）や認証周りの要件を満たせなかった。このため、社内ルールに準拠した形で、違反となるリソース設定をJSON形式で具体的に記述した「AWS Config カスタムルール」を作成し、要件を満たしている。
開発者への粘り強い働き掛け
ダッシュボードを用意しただけでは開発者はセルフレビューしないと考え、管理者側から開発者に対して、多様な手段で継続的な働き掛けをした。具体的には、社内チャットでの情報発信、手動チェックの場でのダッシュボード紹介、セキュリティ講座の開催、やられWebページへの攻撃ハンズオン実施、さらには社外イベントでの登壇を通じて社内での注目度を高めるなど、多角的に啓発活動を展開した。
実績と効果、今後の展望
これらの取り組みによって、セキュリティチェックを大幅に改善できたと角田氏は説明している。
利用者からは「規模が大きいシステムでも1時間程度で確認できた」といった肯定的なフィードバックがあり、開発ベンダーからも継続利用を望む声が上がっているという。本来ブロックすべき通信を許可していた設定ミスを自動検知し、インシデントを未然に防ぐことにも成功した。このインシデント防止が、社内での取り組み拡大の大きなきっかけとなったという。
角田氏は、今後の展望として、現在の草の根的な活動に加え、アプリケーションコードへの対応などセルフチェックしやすい環境づくりや、AIエージェントによるセキュリティリスクの発見、対応依頼の自動化といった新しい技術領域への挑戦を掲げている。
「R&D部門と全社IT部門が連携することで、クラウドネイティブなセキュリティ基準を制定できただけでなく、セルフチェックの仕組みも構築できた。この成功の鍵は、『カスタムポリシーの作成』『ダッシュボードの構築』『開発者への継続的な働き掛け』の3つの要素にあった」と角田氏は振り返った。
Copyright © ITmedia, Inc. All Rights Reserved.