クラスターを保護するための準備

IBM® Cloud Private をインストールするときには、ブート・ノードからクラスター内の他のすべてのノードへのセキュア接続を作成します。 SSH をセットアップするか、クラスター内でパスワード認証をセットアップすることができます。インストール手順については、IBM Cloud Private Cloud Native、Enterprise、および Community Edition のインストールを参照してください。

インストールの後、役割ベースのアクセス制御 (RBAC)、シングル・サインオン (SSO)、および Lightweight Directory Access Protocol (LDAP) によって、クラスターへのアクセスを保護できます。 Helm リポジトリーの管理、名前空間の作成、チームの作成、ポッドおよびコンテナーのセキュリティー・ポリシーの作成が可能です。詳しくは、セキュリティー・ガイドを参照してください。

セキュリティー考慮事項

IBM Cloud Private のセキュリティーを設計する際には、以下の情報を把握している必要があります。

実行しようとしているワークロードのタイプ。
アプリケーションに必要な外部対話のタイプ。
使用しようとしているプラットフォームおよびインターフェースとの対話方法。
ID とアクセス管理 (IAM) および他のセキュリティー・コンポーネントのためのさまざまな統合。
さまざまなグループおよびチームのために必要な分離とセグメンテーション。
各種ワークロードのデータ保護ニーズ。
コンテナーを保護し、変更がないかモニターするために必要な方法。

IBM Cloud Private との対話

誰がどのようにクラスターと対話するのかを理解することは、IAM の構成に役立ちます。アクセスおよび許可を決定するには、使用しようとしているクラスターのターゲット操作モデルを理解する必要があります。以下の事項を明確にしてください。

誰がクラスター管理を行うのか
誰がアプリケーションのデプロイと管理を行うのか
チームはどのような操作を必要とするのか
ロギングおよびモニタリングを含むマルチテナント手法は必要か
どのような認証統合が必要か

統合ポイントが異なると (例えば、継続的インテグレーションと継続的デリバリー (CICD))、サービス・アカウントも、それらのアカウントが必要とする許可も違うものになるため、統合ポイントには特別な注意を払ってください。

コンテナーをデプロイする許可がある状態で CICD デプロイメント・ツールを使用する場合、特定のサービス・アカウントでアクセスおよびデプロイメントを制限し、他のユーザーにこれらのデプロイメントの作成を許可しないようにする必要があります。

詳しくは、セキュリティー・ガイドの『LDAP 接続の構成』および『ポッドの分離』を参照してください。

証明書の取り扱い

証明書は、以下の対話に使用されます。

サービス間通信
- プラットフォーム・サービス (ロギング、モニタリング、計量、およびセキュリティーなど)。
- コア・サービス (Kubernetes や etcd など)。
外部に面しているエンドポイント (イメージ・マネージャー、Docker レジストリー、管理 ingress、Liberty、Helm など)。
- 組み込み (自己署名) 証明書とユーザー提供の証明書の両方がサポートされます。
- IBM Cloud Private プラットフォームで実行されているワークロードによって使用されます (プロキシー Ingress)

証明書ライフサイクルは、手動で管理されるか、または IBM Cloud Private 証明書マネージャー (cert-manager) サービスを使用して管理されます。

cert-manager サービスは、証明書の生成および管理のために使用され、自動更新が組み込まれています。
Kubernetes コミュニティー・プロジェクト cert-manager に基づいています。
サポートされる発行者タイプ: 認証局 (CA)、自己署名、および HashiCorp Vault サーバー。

詳細については、以下のトピックを参照してください。

データ暗号化

転送中データ:

転送中データを保護するために、TLS および IPSec が使用されます。
管理 Ingress コントローラーが TLS をエクスポートし、フロントエンドとして TLS を使用する API がそれを使用できます。
IPSec を使用すると、アプリケーションを変更することなくすぐに、すべてのノード間データ・トラフィックを暗号化できます。詳しくは、IPsec を使用したクラスター・データ・ネットワーク・トラフィックの暗号化を参照してください。
TLS と IPSec の両方とも、Federal Information Processing Standard (FIPS) に準拠する暗号を使用するように構成できます。

保存されたデータ:

どの IBM Cloud Private 状態でも、dm-crypt を使用したボリュームの暗号化に概要が説明されているファイル・システム・レベルまたはブロック・デバイス・レベルの暗号化を使用することによって保護できます。
FIPS 準拠の暗号を使用できます。
秘密を暗号化するために Kubernetes AES-CBC 暗号化プロバイダーを使用可能にすることができます。詳しくは、Kubernetes トピック Encrypting Secret Data at Rest を参照してください。
すべての IBM Cloud Private 秘密は、クラスター管理者またはチーム管理者の役割を持つユーザーのみがアクセス可能です。

Linux で Linux® Unified Key Setup (LUKS) 暗号化を使用して、IBM Cloud Private で使用されるファイル・システムを暗号化できます。システムに使用可能なディスク・スペースがあることを確認してください。 dm-crypt は、ブロック・デバイスの透過暗号化を提供します。デバイスをマウントした直後にデータにアクセスできます。デフォルトでは、IBM Cloud Private クラスター内では転送中データ暗号化は無効にされます。

詳細については、以下のトピックを参照してください。

イメージの保護

IBM Cloud Private には、クラスター内の Docker レジストリーに基づくプライベート・イメージ・リポジトリーがあります。以下に、IBM Cloud Private を使用してイメージを保護する利点をいくつか示します。

バンドルされたイメージ: Docker イメージをバンドルからプライベート・レジストリーにインポートするか、または、複数のノードにわたってデプロイしたい Docker イメージをインポートすることができます。
セキュア・アクセス: 承認したイメージのみを追加して、開発者が信頼して検証したイメージを作成に利用できるようにします。
イメージ・リポジトリーの場所: すべてのローカル Docker レジストリー・イメージは、マスター・ノードに置かれます。複数のマスター・ノードがある場合、レジストリーはアクティブ・モードのマスター・ノード間に分散されます。
外部リポジトリー: 脆弱性アドバイザーは外部リポジトリーをスキャンできません。

どのリポジトリーからイメージをデプロイできるのかを制限できます。脆弱性アドバイザー・ポリシーを適用することもできます。イメージが定義済みのポリシー要件を満たしていない場合、ポッドはデプロイされません。脆弱性アドバイザーを使用する場合、内部イメージ・リポジトリーが使用される必要があります。

コンテナーの保護

コンテナーを保護する主な目的は、プライベート・クラウドで実行されているアプリケーションおよびデータへのアクセスとセキュリティーおよびコンプライアンスの適用のために、可視性、制御、および分析を提供することです。脆弱性アドバイザーおよびミューテーション・アドバイザーを使用して、これらの目的を達成できます。

脆弱性アドバイザーの利点:

開発者は安全なアプリケーションを手間をかけずに設計できます
セットアップは必要ありません
xSP はエージェント資格情報もゲスト資格情報も必要としません
改ざんが防止されます
ほぼリアルタイムで行われるイメージ脆弱性査定がサポートされます
結果を解釈するのが簡単です

使用コンテナーは不変か

IBM Cloud Private では、ファイルおよびプロセスに関してコンテナーの変更を追跡できます。システム保全性モニタリングは、Payment Card Industry Data Security Standard (PCI/DSS) を含む、準拠および監査に関するいくつかの要件の重要部分です。

ミューテーション・アドバイザーは、コンテナーを継続的にモニターして、一定のサンプリングでファイルおよびプロセスの状態を監視します。これは、ミューテーション・アドバイザー・ユーザー・インターフェースのプロファイル・ホワイトリストに示される状態のモジュラー変更を、コンテナーの通常変更として報告します。レポートは、コンテナー別に、各コンテナーでは時系列に、コンテナーでの変更についての通知として表示されます。

詳しくは、『脆弱性アドバイザー』を参照してください。