アクセスを制御してアーティファクトを保護する

このページでは、アーティファクトの保護に役立つ Google Cloud サービスと機能について説明します。

保存データの暗号化

Google Cloud では、デフォルトで、Google が管理する暗号鍵を使用して、自動的に保存されているデータを暗号化します。データを保護する鍵に関連する具体的なコンプライアンス要件や規制要件がある場合は、顧客管理の暗号鍵(CMEK)で暗号化されたリポジトリを作成できます。

アクセス制御

デフォルトでは、すべてのリポジトリは限定公開です。最小権限のセキュリティ原則に従い、ユーザーとサービス アカウントに必要な最小限の権限のみを付与してください。

データの引き出しの防止

データの引き出しを防ぐには、VPC Service Controls を使用して、Artifact Registry とその他の Google Cloud サービスをネットワーク セキュリティ境界内に配置します。

脆弱性スキャン

Artifact Analysis は、一般公開されたパッケージのコンテナ イメージをスキャンしてセキュリティの脆弱性を検出できます。

次のオプションが用意されています。

自動脆弱性スキャン
この機能を有効にすると、コンテナ イメージのパッケージに関する脆弱性が識別されます。イメージが Artifact Registry にアップロードされると、イメージがスキャンされ、イメージを push してから最大 30 日間、新しい脆弱性を検出するためにデータが継続的にモニタリングされます。
On-Demand Scanning API
有効にすると、ローカル イメージ、または Artifact Registry に保存されているイメージを手動でスキャンできます。この機能は、ビルド パイプラインの早い段階で脆弱性を検出して対処するのに役立ちます。たとえば、ビルド後にイメージをスキャンするために Cloud Build を使用し、スキャンによって特定の重大度の脆弱性が検出された場合、Artifact Registry へのアップロードをブロックできます。自動脆弱性スキャンも有効にしている場合は、レジストリにアップロードしたイメージも Artifact Analysis によってスキャンされます。

デプロイ ポリシー

Binary Authorization を使用すると、サポートされている Google Cloud 環境のいずれかにコンテナ イメージをデプロイしようとしたときにサービスによって適用されるポリシーを構成できます。

たとえば、脆弱性スキャン ポリシーに準拠するためにイメージが署名されている場合にのみ、デプロイを許可するように Binary Authorization を構成できます。

未使用イメージの削除

未使用のコンテナ イメージを削除してストレージ コストを削減し、古いソフトウェアを使用するリスクを軽減します。gcr-cleaner など、この作業に役立つツールが数多く用意されています。gcr-cleaner ツールは Google の公式プロダクトではありません。

セキュリティのシフトレフト

情報セキュリティ目標を日々の業務に組み込むことで、ソフトウェア デリバリーのパフォーマンスを向上させ、より安全なシステムを構築できます。この考え方は、「シフトレフト」とも呼ばれます。これは、セキュリティに関する問題がソフトウェア開発ライフサイクルの早い段階で対処されることを意味します(左から右のスケジュール図で左側に位置します)。セキュリティのシフトレフトは、DORA State of DevOps 研究プログラムで特定された DevOps 機能の 1 つです。

詳細を確認する方法:

  • セキュリティのシフトレフト機能についての記事を読む。
  • ホワイトペーパー: セキュリティのシフトレフトをお読みください。これは、ソフトウェア開発ライフサイクル(SDLC)に対する信頼性を高め、セキュリティ リスクの問題を軽減するための責任、プラクティス、プロセス、ツール、テクニックについて説明しています。

公開リポジトリに関する考慮事項

次の場合について注意して検討します。

  • 公開ソースのアトリビュートの使用
  • 独自の Artifact Registry リポジトリを公開する

公開ソースのアセットの使用

次のアーティファクトの公開ソースは、ビルドとデプロイに使用できるツールまたは依存関係を提供します。

ただし、組織には公開アーティファクトの使用に影響する制約が存在する場合があります。次に例を示します。

  • ソフトウェア サプライ チェーンのコンテンツを管理したい。
  • 外部リポジトリを使用したくない。
  • 本番環境で脆弱性を厳密に制御したい。
  • すべてのイメージの基本オペレーティング システムを同じにしたい。

ソフトウェア サプライ チェーンを保護する次のアプローチを検討してください。

  • アーティファクトに一貫性のある既知のコンテンツが含まれるように、自動ビルドを設定します。Cloud Build ビルドトリガーやその他の継続的インテグレーション ツールを使用できます。
  • 標準化されたベースイメージを使用します。Google は、使用可能ないくつかのベースイメージを提供しています。
  • アーティファクトの脆弱性に対処します。On-Demand Scanning API を使用して、コンテナ イメージを Artifact Registry に保存する前に脆弱性をスキャンできます。Artifact Analysis は、Artifact Registry に push したコンテナをスキャンすることもできます。
公開イメージに関する考慮事項の詳細

公開 Artifact Registry リポジトリ

Artifact Registry リポジトリを公開するには、allUsers ID に Artifact Registry 読み取りロールを付与します。

すべてのユーザーが Google Cloud アカウントを所有している場合は、代わりに allAuthenticatedUsers ID を持つ認証済みユーザーのみにアクセスを制限できます。

Artifact Registry リポジトリを公開する前に、次のガイドラインを考慮してください。

  • リポジトリに保存されているすべてのアーティファクトが一般公開可能で、認証情報、個人データ、機密データが公開されないことを確認します。
  • デフォルトでは、プロジェクトのユーザーあたりの割り当てに制限はありません。 乱用を防ぐため、プロジェクト内のユーザーあたりの割り当ての上限値を設定します。
  • ユーザーがアーティファクトをダウンロードすると、ネットワーク データ転送の料金が発生します。大量のインターネット ダウンロードのトラフィックが予想される場合は、関連する費用を検討してください。

ウェブ アプリケーションに関するガイダンス

  • OWASP Top 10 には、Open Web Application Security Project(OSOpenSSL)による、上位のウェブ アプリケーションのセキュリティ リスクが一覧表示されています。

コンテナに関するガイダンス

  • Center for Internet Security(CIS)には、Docker コンテナのセキュリティを評価する Docker ベンチマークがあります。

    Docker には、Docker Bench for Security というオープンソース スクリプトがあります。このスクリプトを使用して、実行中の Docker コンテナを CIS Docker ベンチマークに対して検証できます。

    Docker Bench for Security は、CIS Docker ベンチマークの多くの項目を確認するのに役立ちますが、スクリプトでは検証できない項目もあります。たとえば、コンテナのホストが強化されているか、コンテナ イメージに個人データが含まれているかどうかは確認できません。ベンチマークのすべての項目を確認し、追加の確認が必要な項目を特定してください。

次のステップ

依存関係の管理の詳細