みなさん、こんにちは！株式会社JMDC データウェアハウス開発部 保険者基盤Gの古橋です。
今年、JMDCではアドベントカレンダーに参加しています。
qiita.com
本記事は、JMDC Advent Calendar 2024 19日目の記事です。
はじめに
保険者基盤Gでは、健康保険組合から受領した加入者台帳やレセプト・健診データを扱っており、 弊社が提供する各種保険者データやサービスで利用しています。
保険者基盤Gはいくつかのチームに分かれており、私は加入者台帳を取り扱う台帳チームに所属しています。
台帳データはAWSのS3バケットを経由して各種サービスへ連携しているのですが、
本記事では、その連携用バケットのポリシーを誤って上書きしてしまったときの学びについて書きたいと思います。
ちなみに、私自身のAWS歴は半年ほどです。
学びのきっかけとなった失敗はかなり初歩的な勘違いから始まりますので、温かい目でお付き合いいただけますとうれしいです🙂
AWS CloudFormationとは
台帳チームではAWSのCloudFormationという機能を利用して、リソースの作成や更新を管理しています。
ここで、ご存知の方も多いと思いますが、改めてCloudFormationという機能をおさらいします。
CloudFormationは「Infrastructure as Code」をAWSの環境で実現するための機能です。
作成したいリソースの設定をYAMLやJSONファイルに定義してテンプレート化しておくことで、リソースを自動で作成することができます。
テンプレートで定義したリソース群を「スタック」といい、このスタックを削除するとリソース群をまとめて削除することもできます。
人為的なミスを減らせるメリットが大きいですが、一方で正しく運用しないとリソースを強制的に変更するようなこともできてしまいます😱
経緯
あるとき、連携用データを用いた検証をするために、別アカウントのS3バケットにデータをコピーすることになりました。
コピーするためには、連携用バケットにコピー先アカウントのアクセス許可を設定する必要がありました。
一時的な設定変更だったので、後で破棄するときにスタックを削除するだけでいいように、この許可設定だけのテンプレートを作成しました。
コピー先アカウントのアクセス許可は正常に設定され、データのコピーも問題なくできたので「よしよし」と思っていた翌日、
「連携用バケットにアクセスできないよ」とサービス担当者から連絡を受けました。
変な汗を感じながら確認してみると、連携用バケットのポリシーが上書きされていることに気づきました😰
大きな勘違い
この失敗を経験して、私はCloudFormation(以下Cfnという)について大きな勘違いを2つしていることが分かりました。
勘違い① CloudFormationの定義単位でバケットポリシーを追加設定できるものだと思っていた
これはCfnだけでなく、S3バケットポリシーについての誤解も大きいと思いますが、
Cfnで作成したバケットポリシーを一つのバケットにいくつも設定できると思っていました。
勘違い② CloudFormationの変更セットはリソース情報を比較していると思っていた
Cfnには「変更セット」と呼ばれる変更前後の差分を確認できる機能があります。
この時の変更セットには設定が追加される差分だけで、本番用の設定が消えてしまうような差分は出ませんでした。
①の勘違いをしているので、追加差分だけで問題ないと安心してしまいました。
学んだこと
まず1番の学びは、「CloudFormationの変更セットはテンプレートファイルの差分を表示している」という仕様です。
正確にはテンプレートファイルとパラメータの設定値を比較しています。
ただ漠然と、変更前後のリソース情報自体を比較している便利機能だと思っていたので、今回のことは改めて「何の差分なのか」を意識するきっかけになりました。
「バケットポリシーはバケットに対して1つだけ適用できる」ということも学びでした。
バケットポリシーだけでなくVPCエンドポイントやSQSキューなども、一つのリソースに対して一つのポリシーが適用されるそうです。
そして、チームとして「Cfnの運用方法を見直す必要がある」と感じました。
これまでは変更セットを確認して問題なければデプロイしていましたが、
変更セットがテンプレートファイル自体の比較しかできなということを念頭に置いたデプロイ手順にしなければいけないと思いました。
また、テンプレートを分けてはいけないリソースは何かを整理してチームのルールにしたいと考えています。
改善策の紹介
ポリシーの上書きを完全に予防することはAWSの機能では難しそうです。
しかし、検知を早める仕組みならいくつかできるようなのでご紹介します。
方法① AWS Configルールで更新を監視する
リソースの設定が、ルールに定義した基準に準拠しているかどうかを自動的に評価できます。
通知機能もサポートされているため、迅速に対応することができるようになります。
【ざっくり手順】
- AWS Management Consoleにログインし、AWS Configを設定する
- AWS ConfigのダッシュボードからS3バケットを監視するルールを作成する
方法② AWS Lambdaでポリシー検証
AWS CloudTrailを使用してS3バケットポリシーの変更イベントを監視し、AWS Lambda関数でポリシーを検証する方法です。
リアルタイムに監視し、検証を自動化できます。
任意の検証ロジックを実装できるため柔軟性があります。こちらも通知機能はサポートされています。
【ざっくり手順】
- AWS CloudTrailを設定する
- CloudWatch Eventsルールを作成する
- S3バケットポリシーの変更を検証するLambda関数を作成する
- Lambda関数の実行に必要な権限を持つようにIAMロールを設定する
おわりに
今回の失敗は、幸い大きな影響を及ぼす前に気づき対処することができました。
CloudFormationはファイルとボタン一つでデプロイできる便利な機能である反面、意図しない変更を気づかないうちに行ってしまう危険性もあるのだと改めて感じました。
本記事が、AWS歴浅めの方や同じチームにAWS歴浅めのメンバがいる方々の参考になると嬉しく思います。
最後までお読みいただきありがとうございました！
明日20日目は、八杉さんによる「React で dialog を利用する in 2024」です。お楽しみに！
JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です！フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。 hrmos.co まずはカジュアルにJMDCメンバーと話してみたい／経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。 hrmos.co ★最新記事のお知らせはぜひ X（Twitter）、またはBlueskyをご覧ください！ Tweets by jmdc_tech twitter.com bsky.app
