すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:データ暗号化とキー管理

最終更新日:Nov 11, 2024

データ暗号化とキー管理により、データの保存、送信、処理中に機密データを効率的に保護できます。 さらに、リアルタイムモニタリング、暗号化アルゴリズムの更新、およびキー管理ポリシーは、サイバーセキュリティの進化する脅威に適応し、テクノロジーの課題に対処するのに役立ちます。

データ暗号化

ディスク暗号化に関する提案

  • ディスク暗号化の有効化

    セキュリティのベストプラクティスとして静的暗号化を使用します。 詳細については、「ディスクボリュームの暗号化」をご参照ください。

  • CMKを定期的に回転

    定期的にキーをローテーションし、キーのバージョン管理を設定して、顧客マスターキー (CMK) のセキュリティを強化できます。 詳細については、「自動キーローテーション」をご参照ください。

KMSに保存されたキーを使用してディスクボリュームを暗号化する

Container Service for Kubernetes (ACK) クラスターは、高いセキュリティが必要なシナリオやコンプライアンス要件があるシナリオに適しています。 ACKを使用すると、ストレージ暗号化を使用して、基盤となるキー管理システムを開発および保守する必要なく、ECSインスタンスに保存されたデータのプライバシーと自律性を確保できます。 詳細については、「ディスクボリュームの暗号化」をご参照ください。

このセクションの例では、ディスクボリュームを作成するときに、key Management Service (KMS) に格納されているキーを使用してディスクボリュームを暗号化する方法について説明します。

  1. StorageClassを作成します。

    1. sc-kms.yamlという名前のファイルを作成し、次のコンテンツをファイルにコピーします。

      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: csi-disk
      provisioner: diskplugin.csi.alibabacloud.com
      parameters:
          fsType: ext4
          type: cloud_ssd
          encrypted: "true"
          kmsKeyId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      reclaimPolicy: Delete
    2. 次のコマンドを実行してStorageClassを作成します。

      kubectl create -f sc-kms.yaml
  2. 永続ボリュームクレーム (PVC) を作成します。

    1. sc-pvc.yamlという名前のファイルを作成し、次の内容をファイルに追加します。

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: disk-pvc
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
        storageClassName: csi-disk
    2. 次のコマンドを実行してPVCを作成します。

      kubectl create -f sc-pvc.yaml

キー管理

Kubernetesを使用すると、アプリケーション開発者は、ポッドで使用できるデータベースパスワード、アプリケーション証明書、トークンなどの機密情報をSecretsに保存できます。 次の箇条書きリストは、Secretsに関連する用語を説明しています。

  • 秘密は名前空間にスコープされます。 Kubernetesロールベースのアクセス制御 (RBAC) とともにSecretsを使用して、読み取りと書き込みを名前空間で分離できます。

  • 秘密をファイルまたは環境変数としてポッド内のコンテナにマウントできます。

  • Secretsの機密情報は、ノードの一時ファイルシステム (tmpfs) に格納されます。

  • APIサーバーは、SecretsをBase64-encoded平文としてKubernetesクラスターのetcdに保存します。

  • シークレットのサイズは1 MB未満です。

Kubernetesでアプリケーションの機密情報を保存する容器として、Secretsは機密情報のセキュリティを確保できません。 開発者とセキュリティエンジニアは、Secretsを使用すると次の問題が発生します。

  • 開発者とセキュリティエンジニアは、アプリケーションをデプロイする前に、キー情報を管理し、キーを格納するセキュリティソリューションを決定する必要があります。

  • 開発者とセキュリティエンジニアは、キーの読み込みと使用を損なうことなく、キーの読み取り、書き込み、送信を安全に保つ方法を教えてください。

  • クラウドサービスプロバイダーは、キーのセキュリティを確保するためにどのようなセキュリティソリューションを提供していますか?

  • Kubernetesでキーを管理および保護するために、どのようなセキュリティアプローチを選択する必要がありますか?

上記の問題を解決するには、クラウドサービスプロバイダーが提供するキー管理セキュリティソリューションと、開発者向けのキー管理セキュリティのベストプラクティスを選択することをお勧めします。

セキュリティソリューション

クラウドセキュリティの共有責任モデルに基づいて、クラウドサービスプロバイダーは、コントロールプレーン側の設定と機密情報のセキュリティを確保し、重要な管理セキュリティソリューションを提供する責任があります。 これにより、キーのセキュリティが強化されます。 以下のセキュリティソリューションをお勧めします。

  • クラウドサービスプロバイダーが提供するキー管理サービスの使用

    クラウドサービスプロバイダは、通常、鍵管理サービスを提供する。 たとえば、Alibaba Cloud KMSは、アプリケーションシステム統合の手順を簡素化するために、プロフェッショナルなキーライフサイクル管理およびデータ暗号化 /復号化サービスを提供しています。 KMSの詳細については、「」をご参照ください。KMSとは何ですか?

    データ侵害は、アプリケーションシステムの開発と展開のパイプライン全体で機密情報のハードコーディング中に発生する可能性があります。 ハードコーディングを回避するために、クラウドのキー管理サービスを使用して、アプリケーションの開発、テスト、および構築のパイプライン全体でキーの読み取りと書き込みを行うことができます。 キー管理サービスは自動キーローテーションもサポートしており、機密データ侵害のリスクを軽減し、企業がセキュリティコンプライアンス要件を満たすのに役立ちます。

  • シークレットストアCSIドライバーの使用

    ほとんどの場合、アプリケーションは指定されたファイルシステムパスまたは環境変数からキーを取得する必要があります。 Secret Store CSIドライバを使用すると、キー管理サービスに格納されているキーをコンテナーの指定されたファイルシステムパスにインポートできます。

    Secret Store CSIドライバーsecrets-store-csi-driverは、CSI標準に基づいてKubernetesコミュニティによって開発されました。 secrets-store-csi-driverを使用すると、ボリュームを使用して外部キー管理サービスに格納されているキーをポッドにマウントできます。 ボリュームを使用してキーをマウントした後、キーはファイルシステムを介してコンテナ内で使用できます。 Kubernetesでシークレットを作成する必要はありません。 これにより、etcdにプレーンテキストのSecretsを保存したり、大規模なKubernetesクラスターで多数のSecretsを維持したりする必要がなくなります。 さらに、アプリケーションは、キー管理サービスを呼び出す代わりに、元のファイルパスからキーを取得できます。 これにより、追加コストの発生が回避される。

    secrets-store-csi-driverの助けを借りて、クラウドサービスプロバイダーはバックエンドのさまざまなキー管理サービスとインターフェースすることができます。 たとえば、Alibaba Cloud secrets-store-csi-driver-provider-alibabacloudをクラスターにデプロイして、KMSにファイルまたはKubernetes Secretsとして保存されているキーをコンテナーに同期できます。 さらに、キーの変更をKMSからコンテナーにリアルタイムで自動的に同期して、キーの有効性を確保できます。 secrets-store-csi-driverにはKMSでキーにアクセスするための権限が必要なため、最後のキーの問題を解決するには、サービスアカウントのRAMロール (RRSA) ソリューションを使用できます。 RRSAソリューションでは、ポッドに権限を付与する代わりに、KMSのキーにアクセスするためのSecret Store CSIドライバーのサービスアカウントを承認することができます。

  • etcd暗号化の有効化

    etcdは、Kubernetesクラスターで使用されるデフォルトのストレージシステムです。 秘密は、Base64-encoded平文としてetcdに格納される。 そのため、セキュリティ上のリスクが発生します。 クラウドサービスプロバイダによって提供される管理クラスタでは、etcdはクラウドサービスプロバイダによって維持される。 ゼロ信頼の原則とさまざまなシナリオでのセキュリティコンプライアンス要件のため、Kubernetesが提供するetcd暗号化を使用することを推奨します。 次に、エンベロープ暗号化を使用して、KMSからSecretsに同期するときにキーを自動的に暗号化し、Secretsからキーを取得するときにキーを復号化できます。 Etcd暗号化を自動キーローテーションと併用して、データセキュリティをさらに強化できます。

  • 機密コンテナーの使用

    金融決済、プライバシー認証、知的財産保護に関連するデータコンピューティングなど、強化されたデータセキュリティが必要なシナリオでは、機密情報の読み取り、書き込み、送信を秘密にし、クラウド内の機密情報のインメモリコンピューティングとストレージをさらに保護する必要があります。 上記のシナリオでは、信頼できる実行環境 (TEE) ベースの機密コンピューティングにACKクラスターを使用することを推奨します。 TEEベースの機密コンピューティングのACKは、基盤となるハードウェア暗号化技術に基づいて、信頼できる暗号化実行環境を提供します。 クラウド内のコードスニペット全体で使用される機密情報の整合性を保証し、ライフサイクル全体を通してデータの保護と機密性を保証します。 さらに、アプリケーションシステムによって使用されるキーは、エンクレーブと呼ばれる信頼できる隔離された環境に格納して、キー送信を減らすことができます。 エンクレーブは、KMSのハードウェアセキュリティモジュール (HSM) に似ています。

セキュリティのベストプラクティス

クラウドサービスプロバイダーが提供するキー管理セキュリティソリューションに基づいて、開発者とO&Mエンジニアは自分の側のキーのセキュリティを保証する必要があります。 以下のセクションでは、ビジネス側で推奨されるキー管理セキュリティのベストプラクティスについて説明します。

  • RBAC

    SecretはKubernetesの基本モデルです。 RBAC on Secretsは基本的ですが、データセキュリティに不可欠です。 グローバルSecretsに対する読み取りおよび書き込み権限を提供する資格情報の発行を回避するには、毎日のクラスター開発およびメンテナンス中に最小権限の原則に従う必要があります。 また、公開される可能性のあるクラスター資格情報を取り消す必要があります。

  • ポッドのセキュリティ強化

    コンテナエスケープは、Kubernetesクラスターを対象とする一般的な攻撃です。 コンテナから基盤となるホストにエスケープした攻撃者の場合、ノードのSecretsに格納されているプレーンテキストデータを簡単に取得し、クラスター全体にアクセスしてクラスター内の機密データを盗む権限をエスカレートできます。

    Kubernetesは、開発者がコンテナーのセキュリティを強化するのに役立つ複数のセキュリティ設定を提供します。 開発者は、特権設定、共有ホストネットワーク、または共有ファイルシステムの使用を避けるために、ビジネス要件に基づいて機能を持つポッドの許可を最小限に抑える必要があります。 開発者は、セキュリティポリシーを使用して、アプリケーションの展開中にセキュリティポリシーに準拠しない特権の割り当てを拒否できます。 さらに、ネットワークポリシーを使用して、ポッド間の東西アクセスを規制し、横方向移動攻撃のリスクをさらに減らすことができます。

  • ノードセキュリティ強化

    クラスターインフラストラクチャセキュリティは、アプリケーションセキュリティの基盤です。 可能な場合はプライベートネットワークを選択し、アクセス制御リスト (ACL) ルールをセキュリティグループに追加して、インバウンドトラフィックとアウトバウンドトラフィックを制御する必要があります。 クラスターノードのセキュリティを確保するために、MLPS (Multi-Level Protection Scheme) またはAlibaba Cloud Linux security Hardeningに基づいてセキュリティコンプライアンス標準を定義することを推奨します。 これにより、ID検証、アクセス制御、セキュリティ監査、および侵入防止の観点からインフラストラクチャのセキュリティが強化され、ホスト側での機密データ侵害の可能性が低減されます。 MPLSセキュリティ強化の詳細については、「MLPSに基づくACKセキュリティ強化」をご参照ください。

    Kubernetesクラスターのコンポーネントの設定は、アプリケーションのセキュリティにおいて重要な役割を果たします。 ベースライン検査は、リスクの高い構成とパッチの脆弱性を早期に特定するのに役立ちます。

  • サプライチェーンのセキュリティ強化

    キーは、アプリケーション成果物のライフサイクル全体を通して取得および使用されます。 したがって、企業はキーセキュリティに対する意識を高め、キーの使用をさらに規制する必要があります。 アプリケーションテンプレート、コードリポジトリ、および構成ファイルでの機密情報のハードコーディングを禁止する必要があります。 キー管理サービスは、アーティファクトのサプライチェーン全体でキーを集中管理する必要があります。 さらに、企業の内部セキュリティ管理およびO&Mチームは、サプライチェーンの各コンポーネントでのデータ侵害を防ぐための自動セキュリティ検査メカニズムを開発する必要があります。

  • 監査とモニタリング

    エンタープライズアプリケーションシステムでは、キーの読み取り、書き込み、使用、およびライフサイクル管理に関連するすべての操作を監査およびログに記録して、機密データに対する操作を追跡できるようにする必要があります。 さらに、機密データに対する疑わしい読み書き操作のアラートルールや、Alibaba CloudアカウントのAccessKeyペアの違反のアラートルールなど、ランタイムモニタリングメカニズムが必要です。 これにより、ログとアラートを生成して、O&Mエンジニアが主要な違反を迅速に処理し、影響を評価し、経済的損失を最小限に抑えることができます。

  • 一時トークンの使用、定期的なキーの回転、または自動キー回転の設定

    アプリケーションシステムでは、AccessKeyペアなどの静的キーを使用しないでください。 一時的なトークンを使用することを推奨します。 攻撃者が一時的なトークンに侵入した場合、攻撃者は限られた時間内にのみトークンを悪用できます。 これにより、攻撃者が攻撃を拡大する可能性が最小限に抑えられ、システムO&Mエンジニアがシステムの脆弱性にパッチを当てる機会が提供されます。 長期キーが開示されている場合、脆弱性のパッチ処理作業はより複雑になります。 アプリケーションのセキュリティを強化するために、KMSに格納されているキーを管理するときは、キーを定期的にローテーションするか、キーの自動ローテーション機能を有効にすることを推奨します。

  • エンベロープ暗号化を使用して最後のキーを保護

    クラウド内のキー管理サービスに保存されているキーを使用して平文を直接暗号化するのとは異なり、エンベロープ暗号化では別のキーを使用して暗号化されたキーをエンベロープに渡すことができます。 エンベロープ暗号化の助けを借りて、機密データをビジネス側でオフラインで暗号化および復号化できます。 これにより、キーのクラウドへのアップロードが回避され、クラウドコンピューティングから生じる信頼の問題が解決されます。 大量のデータを暗号化および復号化する必要があるオフラインコンピューティングシナリオでは、エンベロープ暗号化は、クラウドおよびクラウドコンピューティングへのデータ伝送にかかるIT支出を節約し、全体的なパフォーマンスを向上させます。 エンベロープ暗号化の詳細については、「エンベロープ暗号化を使用したローカルデータの暗号化と復号化」をご参照ください。

    最後のキーは、キー管理サービスベースの暗号化および復号化シナリオでよく見られる問題です。 エンベロープ暗号化では、コンテンツ暗号化キー (CEK) を暗号化および復号化するために、キー暗号化キー (KEK) をクラウドに保存する必要があります。 ほとんどのシナリオで最小の特権に基づいてKEKを保護するために、Alibaba Cloud Resource access Management (RAM) などのアクセス制御サービスを使用できます。 アプリケーション側では、クラウドからKEKを取得するために使用されるRAM資格情報へのアクセスを制限する必要があります。 また、RAM資格情報を保護するために、自動的にローテーションされた一時トークンを使用する必要があります。 RRSAと同様の分離メカニズムを使用して、アプリケーションがRAM資格情報にアクセスするのを制限することを推奨します。 詳細については、「RRSA」をご参照ください。