Software Engineerが見たAWS re:Inforce 2024
はじめに
三菱UFJフィナンシャル・グループ（以下MUFG）の戦略子会社であるJapan Digital Design株式会社（以下JDD）でSoftware Engineer（以下SWE）をしている米澤です。
2024年6月にペンシルベニア州・フィラデルフィアで開催されたAWS re:Inforce 2024に現地参加し、イチSWEが感じたクラウドセキュリティについて記載したいと思います。
昨年度の参加レポートはこちらをご覧ください。
参加の経緯
前職ではCCoE（Cloud Center of Excellence）に所属しており、特にAWSマルチアカウント環境下におけるクラウドセキュリティ担保のための仕組み作りを主業としていました。
この手の話をする上で、どうしても避けては通れないのが「セキュリティ事故を発生させないためにルールを厳格にしたい管理者」と「自由にフットワーク軽く開発を行いたい開発者」という2つの異なる立場です。
私自身、現在はSWEとしてクラウドを活用したアプリケーション開発を行っています。CCoEの経験からクラウドにおけるセキュリティ担保の重要性はよく理解しているため、「セキュリティを担保しつつ、様々なクラウドサービスをフル活用して開発スピードを両立するためのプラクティス」に興味を持っています。
CCoE経験のあるSWEだからこそ探ることができる、みんなが幸せになれる新しいクラウドセキュリティのヒントを得たい、そんな思いからre:Inforceに参加しました。
Japan Tourで参加
参加に当たり、AWS様とJTB様が企画された「AWS re:Inforce Japan Tour 2024」を利用して参加させていただきました。
事前説明会はもちろんのこと、Japan Lunch、AWS CISOのChris Betz氏との交流会やAWS NYCオフィス・AWS Builder Studioの視察など、数多くのコンテンツが企画されていたため、初参加のre:Inforceを満喫することができました。企画いただいたAWS様・JTB様 本当にありがとうございます。
参加したセッション
アプリケーション開発におけるセキュリティに関するセッションに多く参加しましたが、その中でも印象に残っているセッションを2つご紹介します。
【APS374】 Enhancing software supply chain security: SBOMs, signing, slimming
先日、トロイの木馬化したjQueryが拡散されたというニュースはご存知でしょうか？
OSSはアプリケーション開発に必要不可欠となっている中、OSSにバックドアや脆弱性を仕込む攻撃手法「ソフトウェアサプライチェーン攻撃」が近年話題となっています。
本ワークショップでは、ECS×Fargateで構成されるアプリケーションにおいて下記の要素をCodePipelineに組み込み、ソフトウェアサプライチェーンの信頼性を高めるという内容でした。
① Amazon InspectorによるSBOM (Software Bill of Materials) 生成
② AWS Signerを用いたイメージ署名による真正性担保
③ コンテナイメージをスリム化することによるセキュア化
近年では組織外部だけではなく、組織内部における不正についても考慮しなければなりません。例えばリリースが自動化されたCICDパイプラインにおいて、意図的に脆弱なアプリケーションコードや不審なライブラリを仕込まれた場合、リリースを事前に食い止めることはできるでしょうか？
本ワークショップ参加前は、SBOMやイメージ署名というワードは知りつつも、具体的な活用イメージが湧いていませんでしたが、具体的なパイプラインへの組み込み方を学ぶ事ができ、非常に学びの多いセッションでした。
また、普段よりコンテナアプリケーションをECS環境上で構築することが多く、すぐにでも既存ワークロードに取り込めそうな実践的な内容のワークショップでした。
【APS342-R1】 Move fast & stay secure: Lessons learned from the AWS prototyping team
こちらのセッションはAWSのプロトタイピングチームにおいて、どのようなツールを用いてセキュリティを担保しているのか？という内容について紹介されていました。
リソース構築にはAWS CDK (Cloud Development Kit) を用いつつ、CDKに特化した静的解析ツールであるcdk-nagを活用し、コーディングの段階から解析を行うというデモをソースコードとともに紹介されていました。
また、AWSのサービス選定においても、責任共有モデルに基づき抽象度の高いAWSマネージドサービス （LambdaやDynamoDBなど）を活用することでセキュリティの関心事をより少ない方向に持っていく、という考え方は今後のアーキテクチャ選定に活かせるな、と改めて感じました。
上記は、マネージドサービスであればあるほど、機能実現のためのリソースインフラ管理をAWS側に任せることができ、開発者が運用保守するべきスコープが狭まるというものです。例えば、AWS Lambdaであれば開発者が運用するものはアプリケーションコードと実行環境の設定情報などがメインとなり、OSランタイムなどの運用は不要となるため、よりアプリケーションロジックの実装に注力ができるようになります。
私自身も業務にてCDKを活用したプロトタイピングを行っているため、こちらのセッションも非常に参考となりました。
2023年度版の資料となりますが、プレゼン資料も公開されているので、興味を持たれた方は是非ご覧いただければと思います。
所感
セッション以外にも AWS Community BuildersのMeetupであるMixerに参加し、海外の方と交流できた他にも、Gamedayへの参加など現地体験を重視し、密度高くイベントを楽しむことができました。
もともとAWSユーザーであったChris Betz氏が仰られていた「AWSがこんなにセキュリティに投資しているとは思わなかった」という発言がとても印象に残っています。
どれだけセキュリティサービスが拡充され、便利になったとしても、セキュリティを自分事として考えてプロアクティブに実現していくという組織文化がなければ、絵に描いた餅となってしまいます。
JapanTour特別プログラムにおけるChris Betz氏の特別講演においても、セキュリティ文化醸成のためのヒントや取り組み事例、課題感などをざっくばらんにお話しされており、自組織に持ち帰れそうな気付きが多くありました。
セキュリティは全員参加
今回のre:Inforce参加を通じて、改めて感じたことは「セキュリティを担保するのはセキュリティチームだけではない」という点です。
私の好きな言葉として「セキュリティは全員参加」というワードがあります。
基調講演等でも触れられていましたが、セキュリティを自分事とし、強いオーナーシップを持つようにするための「Culture of Security」がまさに上記であると感じています。
ソフトウェア開発において、セキュリティ的に脆弱なアプリケーションを開発・運用したいと考えている人はないでしょうし、それを非難したい人ももちろんいないはずです。
如何にストレスなく・楽にアプリケーション開発のフローの中にセキュリティ対策の仕組みを落とし込み、浸透させるかがとても重要だと考えています。また、上記を浸透させるための大前提として、基調講演でも述べられていた「Culture of Security」の醸成は必要不可欠です。もちろんこのような文化の醸成は一朝一夕で実現できるものではないため、AWSが実践しているSecurity Guardians Programを例に習い、セキュリティの専門家を開発チーム内にアサインし、開発チーム内部からセキュリティに関する啓蒙活動を行うボトムアップ型のアプローチも効果的だと改めて感じています。
AWSでは豊富なセキュリティサービスが提供されているため、それらを積極活用し、アプリケーション開発者もプロアクティブにセキュリティ向上に寄与するためのヒントを、re:Inforce参加を通じて多く得ることができました。また、技術的な観点だけでなく組織マネジメントの観点でも気付きがとても多く、開発者やセキュリティ担当者だけでなくマネジメント層の方にもre:Inforceは非常におすすめです。
来年度フィラデルフィアにて開催が決定しているため、是非参加したいと思います。
Appendix.
先日JAWS−UG（AWSのユーザーグループ）において、re:Inforceの振り返り勉強会が開催されました。
こちらにてLTを行った際の資料およびアーカイブ動画も記載しておりますので、ぜひご覧いただければ幸いです。
以上、AWS re:Inforce2024 現地参加レポートでした。
最後までご覧いただきありがとうございました。
Japan Digital Design株式会社では、一緒に働いてくださる仲間を募集中です。カジュアル面談も実施しておりますので下記リンク先からお気軽にお問合せください
この記事に関するお問い合わせはこちらにお願いします。