徳丸氏が解説、クラウドネイティブ環境でWebサービスを立ち上げる際に気を付けるべきポイント：「サービスごとに責任共有モデルが異なることをきちんと理解すべきだ」

「＠IT Cloud Native Week 2024 冬」の基調講演にイー・ガーディアングループCISO 兼 EGセキュアソリューションズ取締役CTO 徳丸 浩氏が登壇。クラウドネイティブ環境でWebサービスを展開する際に気を付けるべきセキュリティのポイントを解説した。

[齋藤公二，＠IT]

　「＠IT Cloud Native Week 2024 冬」の基調講演にイー・ガーディアングループCISO（最高情報セキュリティ責任者）兼EGセキュアソリューションズ取締役CTO（最高技術責任者）の徳丸 浩氏が登壇。「クラウドネイティブなWebサービスにおけるセキュリティの勘所」と題し、クラウドネイティブ環境でWebサービスを展開する際に気を付けるべきセキュリティのポイントを解説した。

DevOpsやマイクロサービス、コンテナにもセキュリティ課題はある

イー・ガーディアングループCISO 兼 EGセキュアソリューションズ取締役CTO 徳丸 浩氏

　著書『体系的に学ぶ 安全なWebアプリケーションの作り方』（通称、徳丸本）やYouTubeチャンネルなど、数多くの媒体での発信や提言を通じて、サイバーセキュリティ業界の発展に貢献し続けている徳丸氏。冒頭、クラウドネイティブの目的をこう解説した。

　「クラウドネイティブの目的は柔軟性と迅速性にあります。Webサービスを提供していく上では、ニーズの変化、環境の変化、スケールの変化に柔軟に対応することが求められます。近年、アジャイル開発やスクラムのような手法が取り入れられるようになりましたが、本番環境に適用する速度がボトルネックとなりました。そこで、Devの部分（企画、開発、ビルド、テスト）とOpsの部分を（リリース、デプロイ、運用、監視）を一体化して自動化するDevOpsが重視されるようになりました。一方、巨大なシステムを開発、運用する1000人規模のチームでアジャイル開発は困難です。そこでシステムを小さい単位（サービス）に分割し、それぞれのサービスを小さなチームで管理しようという考え方が生まれました。ただ小さく分けるだけではなく、お互いの影響がないように疎結合に分割しようという考え方がマイクロサービスです。マイクロサービスで実装することで、新機能の追加など何かしらの変更や拡張時に、システムへの影響を最小限に抑えることができます」

マイクロサービスは変更、拡張が容易（徳丸氏の講演資料より）

　一方、徳丸氏は「クラウドネイティブ技術ごとにセキュリティの課題がある」と指摘した。

　「クラウドネイティブ技術として挙げられているCI/CD（継続的インテグレーション／継続的デリバリー）、マイクロサービス、コンテナ、コンテナオーケストレーション（DockerやKubernetes）のそれぞれにセキュリティ課題があります。脅威分析を通じて脅威ごとの優先度を整理し、対応する必要があるでしょう。またWebシステムのセキュリティ課題は依然としてあります。ネットワークや認証、認可の設定、ライブラリの脆弱（ぜいじゃく）性などです。DevOpsの流れで、自動化して対応することが求められます」

サービス連携の不備は重大インシデントを引き起こすリスクに

　徳丸氏は、マイクロサービスを例にセキュリティ課題を説明した。

　「SQLインジェクションの問題があります。アプリケーションをマイクロサービスとして分割したことでサービス間通信や分散トランザクション、サービス間連携も問題になります。個人情報管理サービスとメール送信サービスをマイクロサービスに分割した際、サービス間連携に不備がある場合、攻撃者が途中でメールアドレスを改ざんし、第三者にメールを送信できてしまいます」（徳丸氏）

　サービス間連携の不備により攻撃につながった類似ケースとして「7pay（セブンペイ）」がある。外部ID連携機能に不備があり、SNSのIDで認証後、7payのサーバに処理を引き継ぐ際、別人に成り済まして個人情報を盗み取ることができたという。単純なJSONでやりとりしていたことから、認証トークンなどを簡単に読み取ることができたためだ。7payで起きたセキュリティインシデントの直接原因ではないものの、サービス間連携の不備が、重大インシデントを引き起こすリスクを示す例だという。

　「サービス間連携におけるセキュリティ対策の一つは、APIゲートウェイの利用です。スマートフォンアプリから直接複数のサービスを利用する場合、サービス連携の間で改ざんされる可能性があります。スマートフォンアプリとサービスの間にAPIゲートウェイを挟むと、攻撃者によるサービス間通信の改ざんはできなくなります。あるいは、デジタル署名で改ざん防止機能を持たせたデータ形式（JWT）を使うこともできます。いずれにしても、システム内部でデータが改ざんされるというリスクは、従来のモノリシックなアプリケーションではなかったことです」

　徳丸氏は、コンテナ環境のセキュリティ脅威について「コンテナの一つが汚染されマルウェアのような状態でサーバOSまで到達する『コンテナエスケープ』攻撃がある」とした上で、脆弱性や設定不備によりコンテナイメージが汚染し、セキュリティインシデントにつながるリスクがあることを解説した。

責任共有モデルの違いや責任範囲の違いが落とし穴になることも

　ベンダーとユーザーがそれぞれの責任でレイヤーごとに管理を分担する「責任共有モデル」の在り方も、クラウドネイティブ環境では異なってくる。

　「Amazon Web Services（AWS）で利用できるコンテナ環境の一つに『Amazon Elastic Container Service （Amazon ECS）』があります。Amazon ECSは、『Amazon Elastic Compute Cloud（Amazon EC2）』で利用する場合と、マネージドサービスの『AWS Fargate』で利用する場合とで、責任範囲が変わります。Fargateを利用すれば、ユーザー側で管理する範囲は減る一方、料金も高くなります。Amazon EC2を利用する場合、ユーザー側で責任を持たないといけない範囲が増えます。これらを意識していないと危険です。サーバレスの『AWS Lambda』は、もともと用意されているライブラリはAWSによる管理ですが、アプリケーション固有で使うライブラリはユーザー側で管理する必要があります」

Amazon EC2でECSを利用する場合の責任範囲と、FargateでAmazon ECSを利用する場合の責任範囲の違い（徳丸氏の講演資料より）

　また徳丸氏は、脆弱性を生み出してしまう「メンタルモデル」の改善も重要だと指摘する。大規模な個人情報流出の事例としてグローバルでセキュリティ研究の対象にもなっている、2019年に米金融大手CapitalOneから1億人を超える個人情報が流出したケースでは、インシデントの原因の一つとしてメンタルモデルが挙げられているという。

　脆弱性を生み出してしまうメンタルモデルの例は「新しいクラウドネイティブ技術は、従来の実績ある成熟したセキュリティ技術よりも優れているという思い込み」「クラウドプロバイダーへの盲信や自らの責任の放棄」「『環境が複雑だから専門知識を持たない攻撃者に侵入される可能性は低い』という誤った考え」「開発者は自由にプログラミング言語を選択できるが、それによりセキュリティエンジニアのコードレビューが困難になった（ガバナンスの不足）」などだ。

　「CapitalOneのケースは5年前ですが、今の日本企業にも通用する教訓です。サービスごとに責任共有モデルが異なることをきちんと理解し、自社が利用しているクラウドサービスの責任範囲がどうなっているかを都度確認する必要があります」

複雑なクラウドネイティブ環境で脅威分析を進めるポイント

　徳丸氏は、クラウドネイティブな環境における脅威分析の重要性を示すもう1つの例として、メルカリの事例を紹介した。

　「Webサービスだけでなく、CI/CD環境の中にも脅威があります。メルカリでは、社内で利用していたテストの網羅性を調べるコードカバレッジツールが不正アクセスを受け、開発環境がマルウェア感染したような状況になりました。ソースコードの漏えいに加え、ソースコードのリポジトリに含まれていた個人情報の流出にもつながりました。メルカリは対策として、環境のどこかがマルウェアで汚染されても影響を最低限にする緩和策を実施しています。具体的には、ソースコードリポジトリなどに個人情報を置かない、脆弱性管理の徹底、流出したソースコードから脆弱性を突くような攻撃への備えです」

　徳丸氏は、PLAIDからの依頼を受けて実施した脅威分析を例に、実施のポイントをこう解説した。

　「脅威分析をしたのは、マイクロサービスで構築されている複雑なシステムでした。サービスごとのインプット／アウトプットに注目して脅威分析を開始しましたが、対象となるサービスも多く、複雑だったためすぐにやめました。そこで、典型的なユースケースを基にデータフローを描き、データをたどりながらどのような脅威があるかを調査する方法で対応しました。特にマイクロサービスの場合はこうなりがちですので、脅威分析も対象に応じて適切な方法で取り組んでいくことが重要です」

DevSecOpsによる素早い脆弱性対応も必要に

　徳丸氏は最後のトピックとして、DevSecOps環境における脆弱性対応を解説した。

　「クラウドネイティブは迅速に開発し、迅速にアプリケーションをデプロイすることが出発点です。DevSecOpsはDevOpsにセキュリティを組み込むものです。DevOpsの各ステップでセキュリティの施策を自動化して組み込んでいきます」

　設計段階で脅威を分析し、その脅威への対策を機能として組み込む。実装後は、静的診断（SAST：Static Application Security Testing、SCA：Software Composition Analysis）で脆弱性診断を実施する。ビルドして実行できたら動的診断（DAST: Dynamic Application Security Testing）を実施する。テストができるようになったら、手動での脆弱性診断や、できるだけ開発の早い段階で自動化された脆弱性診断をする。「Log4Shell」のように、汎用（はんよう）ライブラリにある日突然、脆弱性が見つかることもあるため、デプロイ後の脆弱性対応も欠かせない。最新の脆弱性情報も収集し、スキャンを自動化するなど監視部分の工夫も必要になる。

　徳丸氏はクラウドネイティブなWebサービスにおけるセキュリティの勘所を次のようにまとめ、講演を締めくくった。

　「Webサービス開発において、変化への素早い対応が求められています。その解決策としてDevOps、マイクロサービス、コンテナなどの要素技術があります。これらを総称してクラウドネイティブと呼んでいます。クラウドネイティブ技術にはセキュリティ課題があります。個別の課題解決や脅威分析を通じてサービスレベルで脅威、リスクを洗い出し、セキュリティ要件の整理と対策が求められます。これらを含めたDevSecOpsによる素早い脆弱性対応も重要です」