運営が話したい事を一方的に話す時間 ～開発・保守・セキュリティ～

2026年9月5～6日開催
JAWS SONIC 2026の広島支部資料

Transcript

1. #jawsug #jawssonic2026 運営が話したい事を一方的に 話す時間 ～開発・保守・セキュリティ～ JAWS-UG 広島支部 Tetsuya Mito Satoshi Kaneyasu Masaki Mori
2. 広島支部紹介
3. 広島支部について 設立：2012年 ※沼口さん資料を拝借
4. 広島支部 運営メンバー 丸本 健二郎 兼安 聡 三戸 鉄也 AWS HERO AWS Ambassadors https://jawsug-hiroshima.connpass.com/ メンバー絶賛募集中！ 西浜 正人 森 将記
5. Well-ArchitectedやLensとかの関係性や 使いどころを整理したい！ 森 将記
6. 自己紹介 某地方銀行 IT統括部 ※調べたら一発でばれちゃいますが、ヒヨった書き方にさせてもらっています… 森 将記（もり まさき） JAWS-UG広島支部 運営（2025/4～） ＜好きなAWSサービス＞ 最近はPrivateLinkとBackup推し ＜経歴＞ 2009年4月 2014年8月 2020年4月 2021年4月 2025年3月 独立系SIerに新卒入社 某地方銀行に転職 クラウド担当になる クラウドを触り始める JAWSにハマる
7. 背景 ・諸事情でAWSにシステム構築する際のセキュリティの考え方を整理する必要が発生 ・Well-Architected FrameworkやLens、リファレンスアーキテクチャの存在は認識 ・金融業界にはFISC安全対策基準というクラウド関係なく遵守すべきルールも存在 ※それ以外にも金融庁のガイドラインや各種法律もあり ・色々見ていく中で、そもそもそれぞれの関係性や、使いどころがよくわからなくなってしまった… 全体の関係性や使いどころがパッと見てわかるようなものが欲しい！ ※自分なりに整理してみましたが、正直量が多すぎて完璧なものにするのはムリゲー！ つよつよの視聴者の方からたくさん指摘してもらってブラッシュアップしたいです！
8. 自分なりに関係性を整理してみた AWS外部 AWS 金融業界標準 AWS設計原則 ・FISC ・金融分野における サイバーセキュリティガイドライン など ・Well-Architected Framework ⇒ 教科書（基礎）のイメージ 社内標準 ・規定 ・既存のガイドライン など ・FSI※ Lens ⇒ 専門書のイメージ ※Financial Services Industry 各種法令 ・個人情報保護法 ・マイナンバー法 など 特定領域ベスプラ (各種Lens) 実装例 注) FISCの内容を全て 網羅しているわけではない ・金融リファレンスアーキテクチャ （FSI Lens for FISC） ・セキュリティリファレンスアーキテクチャ ⇒ 参考書のイメージ 注) Lensとついているが、 金融リファレンスアーキテクチャの一部 各サービス ドキュメント ・IAM など
9. 各フェーズでの軽重を整理してみた ※詳細設計まで 要件定義 AWS設計原則 （Well-Architected Framework） 特定領域ベストプラクティス Ａ （FSI Lens など） Ｗ Ｓ リファレンスアーキテクチャ （金融、FSI Lens for FISC など） 基本設計 要件定義～基本設計で主に使用 基本設計で主に使用 要件定義～基本設計で主に使用 各サービスドキュメント 詳細設計で主に使用 （IAM、VPC など） 各種法令 Ａ Ｗ Ｓ 外 部 （個人情報保護法、マイナンバー法 など） 金融業界標準 （FISC、金融庁ガイドライン など） 社内標準 （規定、既存のガイドライン など） 詳細設計 要件定義で主に使用 要件定義～基本設計で主に使用 全フェーズで使用
10. コンテナの脆弱性対応で 腰が重くならないためのルール作り
11. AWSにおけるコンテナのセキュリティ運用 • 一般的にはコンテナイメージをAmazon ECRにおいて、 Amazon Inspector で脆弱性検知、AWS Security Hubに集約 Pull Amazon ECS • 集約 スキャン Amazon ECR Amazon Inspector AWS Security Hub いくつかのルールを整備をしておかないと腰が重くなる ◦ やりにくい作業のままだと、保守工程で下手すると押し付け合いになる ◦ 一番怖いのは誰も興味がなくなること
12. 整備すべきこと① 脆弱性対応した後の動作確認手順 • 一番大事なのは脆弱性対応した後の動作確認手順 • どこまでやればいいのか不明瞭なのが一番敬遠される • • • 正常系のみでも全然アリ、ただしそれでよいことを明言はしてあげるべき 責任範囲を明確にしないと誰も手を出すことができない リグレッションテスト（回帰テスト）をして欲しいのなら、 テストケースとテストデータは必ず準備 個人的にこれだけは絶対にアプリチームの責務だと思う
13. 整備すべきこと② 脆弱性対応手順の方針 • 基本的にベースイメージを更新が望ましい ◦ • 影響範囲が心配なのはわかるが、 パッケージ管理は整合性が重要なのでピンポイント対応を是としない方が良いと思う ベースイメージのバージョンはハッシュで指定 ◦ 同じバージョンでもいつの間にか微妙に変わってることはあり得る • apt-getなどでパッケージ単位でパッチ適用せざるを得ない場合は、 必ずバージョンを指定 • バージョンを指定しないパッチ適用（例：apt-get install --only-upgrade） を是としてしまうと、「タイミングによって中身が違う」という心配事が増える
14. コンテナイメージ、厳密には時期によって中身が違う問題 • apt-get install --only-upgradeだと厳密には左右のパイプラインがプッシ ュするコンテナイメージは同じとは言い難い 開発 本番 Git Git Push Push AWS CodeBuild AWS CodeDeploy Amazon ECR AWS CodeBuild AWS CodeDeploy Amazon ECR
15. 整備すべきこと③ 古いイメージの対処ルール • コンテナ脆弱性対応は新しいイメージを作ってアップすること • 何もしないと古いイメージがInspectorに引っかかり続けてやる気が削がれる • 古いイメージの削除条件、Inspectorのスキャン条件を設定する Fargateかつバッチ系 Fargateを使ってない／常時稼働系 • • Fargateは起動時に必ずPull バッチ系は起動タイミング決まっている • • • こちらなら、ECRのライフサイクルポリシ ーで最後のPullからの経過日数で削除でよ いかと • • いつPullするか読めない Inspector側で抑制ルールを使用して古い イメージをスキャン対象外にする 抑制ルールはイメージの最終使用日時で判 定が可能（参考） タグで運用もアリとは思う
16. まとめ • コンテナの脆弱性対応は、各種ルールで腰が重くなる要因を排除！ みんながやってくれる状況を作りましょう！
17. Amplify Gen1 → Gen2 広島支部 #jawsug #jawssonic2026 を真面目に考える 三戸
18. Amplify Gen1 つこうとった？ ウチでも２社ほど納品してる。 １社はバリバリ基幹業務で使うとる。 Vuetify with VTL カスタムなやつら ユーザーインターフェース
19. 一昨年くらいのUG懇親会でgen1 の話して微妙な顔される。 それ以前にも OpsWorks で微妙な反応を喰らう。
21. migration ツールが提供されておりまして amplify gen1 （ amplifyコマンド）の v 1.14.0 以上から使える。 ※事前に CDK Bootstrap しておく必要があります CLIから cdk bootstrap が楽。 Assessment For Migrating "billingsystem" (env: dev) Resources ┌──────────┬─────────────────────────┬───────────────────────────────┬──────────┬────────────────┐ │ Category │ Service │ Resource │ Generate │ Refactor │ ├──────────┼─────────────────────────┼───────────────────────────────┼──────────┼────────────────┤ │ api │ AppSync │ billingsystem │ │ — (not needed) │ ├──────────┼─────────────────────────┼───────────────────────────────┼──────────┼────────────────┤ │ auth │ Cognito-UserPool-Groups │ userPoolGroups │ │ │ ├──────────┼─────────────────────────┼───────────────────────────────┼──────────┼────────────────┤ │ auth │ Cognito │ westsigma2024042981cf5404 │ │ │ ├──────────┼─────────────────────────┼───────────────────────────────┼──────────┼────────────────┤ │ custom │ customCDK │ batchMutationResolvers │ │ │ ├──────────┼─────────────────────────┼───────────────────────────────┼──────────┼────────────────┤ │ function │ Lambda │ exportAllPaymentLeftTOs │ │ — (not needed) │ ├──────────┼─────────────────────────┼───────────────────────────────┼──────────┼────────────────┤ │ function │ Lambda │ exportAllPaymentLeftTWs │ │ — (not needed) │ ├──────────┼─────────────────────────┼───────────────────────────────┼──────────┼────────────────┤ │ function │ Lambda │ exportAllPaymentTOs │ │ — (not needed) │ ├──────────┼─────────────────────────┼───────────────────────────────┼──────────┼────────────────┤ assess (事前調査)コマンドがあって 移行可能度合いをチェックしてくれる。 移行できるよ的に表示されてますね。
22. んじゃ migration ・ap-northeast-3 だとS3つかってるとコケる。（回避策無し） S3 Transfer Acceleration 使おうとしてコケる。 ・えげつないCfn生成する。 クソデカ Root… 。 ・VTLつかってたらダメ。 そもそもカスタム ・function(Lambda)周りもダメ。 CDKに対してほとんど対応してない。 SECRETつこうてくれん。 nodejs 以外はサポート外ぞ！
23. んじゃ migration ・ap-northeast-3 だとS3つかってるとコケる。（回避策無し） S3 Transfer Acceleration 使おうとしてコケる。 ・えげつないCfn生成する。 クソデカ Root… 。 まだ使い物にならんレベル！ ・VTLつかってたらダメ。 そもそもカスタム ・function(Lambda)周りもダメ。 CDKに対してほとんど対応してない。 SECRETつこうてくれん。 nodejs 以外はサポート外ぞ！
24. migration のクオリティ UP 待つか、力業で押すか …。
25. migration のクオリティ UP 待つか、力業で押すか …。 gen2 -migration の issue open/close 集計 なお、 97% がメンテナ自身の起票。 developer preview 公開 v14.5.1 migration の修正無し v14.5.0 バグ修正&機能追加 v14.4.0 で正式にリリース
26. migration のクオリティ UP 待つか、力業で押すか …。 gen2 -migration の issue open/close 集計 うん。 自分で頑張ろう。 なお、 97% がメンテナ自身の起票。 developer preview 公開 v14.5.1 migration の修正無し v14.5.0 バグ修正&機能追加 v14.4.0 で正式にリリース
27. ご清聴ありがとうございました！ 引き続き、JAWS SONIC 2026をお楽しみください！！