SEC06-BP04 ソフトウェアの整合性を検証する - AWS Well-Architected Framework
実装のガイダンスリソース

SEC06-BP04 ソフトウェアの整合性を検証する

暗号化技術による検証を用いて、ワークロードが使用するソフトウェアアーティファクト (イメージを含む) の整合性を検証します。 コンピューティング環境内で行われる不正変更への対策として、暗号化技術を用いてソフトウェアに署名します。

期待される成果: すべてのアーティファクトが、信頼できるソースから入手されます。ベンダーのウェブサイトの証明書が検証されています。 ダウンロードしたアーティファクトは、署名により暗号化技術を用いて検証されます。独自のソフトウェアは暗号化技術を用いて署名され、コンピューティング環境によって検証されます。

一般的なアンチパターン:

  • 定評あるベンダーのウェブサイトを信頼してソフトウェアアーティファクトを入手しているが、証明書の有効期限の通知を無視している。 証明書が有効であることを確認せずにダウンロードを続行する。

  • ベンダーウェブサイトの証明書を検証するが、これらのウェブサイトからダウンロードしたアーティファクトについては、暗号化技術による検証を行わない。

  • ソフトウェアの整合性の検証をダイジェストまたはハッシュのみに頼っている。 ハッシュでは、アーティファクトが元のバージョンから変更されていないことは確認できますが、ソースは検証されません。

  • 独自のソフトウェア、コード、またはライブラリに署名しない。独自のデプロイでしか使わない場合でも署名は必要です。 

このベストプラクティスを活用するメリット: ワークロードが依存するアーティファクトの整合性を検証することで、マルウェアがコンピューティング環境に侵入するのを防ぐことができます。 ソフトウェアに署名することで、コンピューティング環境での不正実行を防ぐことができます。  コードに署名して検証することで、ソフトウェアサプライチェーンが保護されます。

このベストプラクティスが確立されていない場合のリスクレベル: 中

実装のガイダンス

オペレーティングシステムイメージ、コンテナイメージ、コードアーティファクトは、多くの場合、ダイジェストやハッシュなどによる整合性チェックが可能な状態で配布されます。 その場合、クライアントはペイロードのハッシュを独自に計算し、それが公開されたものと同じであることを検証することで、整合性を検証できます。 こうしたチェックでは、ペイロードが改ざんされていないことは確認できますが、ペイロードが元のソース（出所）からのものであるかどうかは検証されません。 出所を確認するには、信頼できる機関がアーティファクトにデジタル署名するために発行した証明書が必要です。

ダウンロードしたソフトウェアまたはアーティファクトをワークロードで使用している場合は、プロバイダーがデジタル署名検証用の公開鍵を提供しているかどうかを確認してください。 AWS では、公開しているソフトウェアの公開鍵と検証手順を提供しています。その一例を以下に紹介します。

イメージの取得とハードニングに使用するプロセスにデジタル署名検証を組み込んでください。詳細については、「SEC06-BP02 ハードニングしたイメージからコンピューティングをプロビジョニングする」を参照してください。

AWS Signer を使用すると、署名の検証だけでなく、独自のソフトウェアやアーティファクトのコード署名ライフサイクルも管理できます。 AWS Lambda と Amazon Elastic Container Registry は両方とも Signer に統合でき、コードやイメージの署名を検証できます。 「リソース」セクションの例を参考にして、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに Signer を組み込んで、署名の検証と独自のコードやイメージへの署名を自動化できます。

リソース

関連するドキュメント:

関連する例:

関連ツール: