|
| 1 | +--- |
| 2 | +title: "クラウドネイティブセキュリティとKubernetes" |
| 3 | +linkTitle: "クラウドネイティブセキュリティ" |
| 4 | +weight: 10 |
| 5 | + |
| 6 | +# The section index lists this explicitly |
| 7 | +hide_summary: true |
| 8 | + |
| 9 | +description: > |
| 10 | + クラウドネイティブワークロードを安全に保つためのコンセプト。 |
| 11 | +--- |
| 12 | + |
| 13 | +Kubernetesはクラウドネイティブアーキテクチャに基づいており、クラウドネイティブ情報セキュリティのグッドプラクティスに関するアドバイスを{{< glossary_tooltip text="CNCF" term_id="cncf" >}}から受けています。 |
| 14 | + |
| 15 | +このページを読み進めることで、安全なクラウドネイティブプラットフォームをデプロイするためにKubernetesがどのように設計されているかについての概要を知ることができます。 |
| 16 | + |
| 17 | +## クラウドネイティブ情報セキュリティ |
| 18 | + |
| 19 | +{{< comment >}} |
| 20 | +このホワイトペーパーにはローカライズされたバージョンがあります。 |
| 21 | +ローカライズする際に、そのうち1つをリンクすることができれば、さらに良いでしょう。 |
| 22 | +{{< /comment >}} |
| 23 | + |
| 24 | +クラウドネイティブセキュリティに関するCNCF[ホワイトペーパー](https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)では、さまざまな _ライフサイクルフェーズ_ に適したセキュリティコントロールとプラクティスが定義されています。 |
| 25 | + |
| 26 | +## _Develop_ ライフサイクルフェーズ {#lifecycle-phase-develop} |
| 27 | + |
| 28 | +- 開発環境の整合性を確保します。 |
| 29 | +- 状況に応じて、情報セキュリティのグッドプラクティスに沿ったアプリケーションを設計します。 |
| 30 | +- エンドユーザーのセキュリティをソリューション設計の一部として考慮します。 |
| 31 | + |
| 32 | +これを実現するためには、次のようなことができます: |
| 33 | + |
| 34 | +1. 内部の脅威であっても、攻撃対象となる範囲を最小限に抑える[ゼロトラスト](https://glossary.cncf.io/ja/zero-trust-architecture/)のようなアーキテクチャを採用します。 |
| 35 | +1. セキュリティの懸念を考慮したコードレビュープロセスを定義します。 |
| 36 | +1. システムまたはアプリケーションの _脅威モデル_ を作成し、信頼境界を特定します。 |
| 37 | + そのモデルを使用してリスクを特定し、それらのリスクに対処する方法を見つけるのに役立てます。 |
| 38 | +1. _ファジング_ や[セキュリティカオスエンジニアリング](https://glossary.cncf.io/ja/security-chaos-engineering/)のような高度なセキュリティ自動化を組み込みます。 |
| 39 | + |
| 40 | +## _Distribute_ ライフサイクルフェーズ {#lifecycle-phase-distribute} |
| 41 | + |
| 42 | +- 実行するコンテナイメージのサプライチェーンのセキュリティを確保します。 |
| 43 | +- クラスターとその他のコンポーネントがアプリケーションを実行するためのサプライチェーンのセキュリティを確保します。 |
| 44 | + 他のコンポーネントの例としては、クラウドネイティブアプリケーションが永続性のために使用する外部データベースがあります。 |
| 45 | + |
| 46 | +これを実現するためには、次のようなことができます: |
| 47 | + |
| 48 | +1. 既知の脆弱性を持つコンテナイメージやその他のアーティファクトをスキャンします。 |
| 49 | +1. ソフトウェアのディストリビューションが、ソフトウェアのソースに対するトラストチェーンを使用して、転送中の暗号化を行うようにします。 |
| 50 | +1. 利用可能になった更新に対応するための依存関係の更新プロセスを採用し、それに従います。 |
| 51 | +1. サプライチェーンを保証するために、デジタル証明書などの検証メカニズムを使用します。 |
| 52 | +1. セキュリティリスクを通知するためのフィードや他のメカニズムにサブスクライブします。 |
| 53 | +1. アーティファクトへのアクセスを制限します。 |
| 54 | + コンテナイメージを[プライベートレジストリ](/ja/docs/concepts/containers/images/#using-a-private-registry)に配置し、認証されたクライアントのみがイメージを取得できるようにします。 |
| 55 | + |
| 56 | +## _Deploy_ ライフサイクルフェーズ {#lifecycle-phase-deploy} |
| 57 | + |
| 58 | +何をデプロイできるか、誰がデプロイできるか、どこにデプロイできるかに関する適切な制限を確保します。 |
| 59 | +コンテナイメージアーティファクトの暗号化されたアイデンティティを検証するなど、_Distribute_ フェーズからの対策を適用できます。 |
| 60 | + |
| 61 | +Kubernetesをデプロイすると、アプリケーションのランタイム環境の基盤、つまりKubernetesクラスター(または複数のクラスター)も設定されます。 |
| 62 | +ITインフラストラクチャは、より高いレイヤーが期待するセキュリティ保証を提供する必要があります。 |
| 63 | + |
| 64 | +## _Runtime_ ライフサイクルフェーズ {#lifecycle-phase-runtime} |
| 65 | + |
| 66 | +Runtimeフェーズは、[コンピューティング](#protection-runtime-compute)、[アクセス](#protection-runtime-access)、および[ストレージ](#protection-runtime-storage)の3つの重要な領域から構成されます。 |
| 67 | + |
| 68 | +### Runtime保護: アクセス {#protection-runtime-access} |
| 69 | + |
| 70 | +Kubernetes APIはクラスターを機能させるためのものです。 |
| 71 | +このAPIを保護することは、効果的なクラスターセキュリティを提供するための鍵となります。 |
| 72 | + |
| 73 | +Kubernetesドキュメント内の他のページでは、アクセスコントロールの特定の側面を設定する方法について詳しく説明しています。 |
| 74 | +[セキュリティチェックリスト](/docs/concepts/security/security-checklist/)には、クラスターの基本的なチェックを行うための提案が記載されています。 |
| 75 | + |
| 76 | +さらに、APIアクセスのための効果的な[認証](/ja/docs/concepts/security/controlling-access/#authentication)と[認可](/ja/docs/concepts/security/controlling-access/#authorization)を実装することがクラスターのセキュリティを確保することにつながります。 |
| 77 | +[サービスアカウント](/ja/docs/concepts/security/service-accounts/)を使用して、ワークロードとクラスターコンポーネントのセキュリティアイデンティティを提供および管理します。 |
| 78 | + |
| 79 | +KubernetesはTLSを使用してAPIトラフィックを保護します。 |
| 80 | +(ノードとコントロールプレーン間のトラフィックを含めて)TLSを使用してクラスターをデプロイし、暗号化キーを保護してください。 |
| 81 | +[CertificateSigningRequests](/docs/reference/access-authn-authz/certificate-signing-requests/#certificate-signing-requests)にKubernetes独自のAPIを使用する場合は、その悪用を制限するために特に注意を払ってください。 |
| 82 | + |
| 83 | +### Runtime保護: コンピューティング {#protection-runtime-compute} |
| 84 | + |
| 85 | +{{< glossary_tooltip text="コンテナ" term_id="container" >}}は、異なるアプリケーション間の分離と、それらの分離されたアプリケーションを同じホストコンピューターで実行するメカニズムの2つを提供します。 |
| 86 | +これらの2つの側面、分離と集約は、ランタイムセキュリティとのトレードオフがあり、適切なバランスを見つける必要があることを意味します。 |
| 87 | + |
| 88 | +Kubernetesは実際にコンテナを設定して実行するために{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}に依存しています。 |
| 89 | +Kubernetesプロジェクトは特定のコンテナランタイムを推奨しておらず、選択したランタイムが情報セキュリティの要件を満たしていることを確認する必要があります。 |
| 90 | + |
| 91 | +ランタイムでコンピューティングを保護するために、次のことができます: |
| 92 | + |
| 93 | +1. アプリケーションの[Podのセキュリティ標準](/ja/docs/concepts/security/pod-security-standards/)を強制することで、アプリケーションが必要な権限のみで実行されるようにします。 |
| 94 | +1. コンテナ化されたワークロードを実行するために、特別に設計されたオペレーティングシステムをノード上で実行します。 |
| 95 | + これは通常、コンテナの実行に不可欠なサービスのみを提供する読み取り専用オペレーティングシステム(_イミュータブルイメージ_)に基づいています。 |
| 96 | + |
| 97 | + コンテナ固有のオペレーティングシステムは、システムコンポーネントを分離し、コンテナエスケープが発生した際の攻撃対象領域を減らすのに役立ちます。 |
| 98 | +1. [ResourceQuotas](/ja/docs/concepts/policy/resource-quotas/)を定義して、共有リソースを公平に割り当て、Podがリソース要件を指定できるようにするために[LimitRanges](/ja/docs/concepts/policy/limit-range/)などのメカニズムを使用します。 |
| 99 | +1. 異なるノード間でワークロードを分割します。 |
| 100 | + Kubernetes自体またはエコシステムのいずれかから[ノードの分離](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-isolation-restriction)メカニズムを使用して、異なる信頼コンテキストのPodが別個のノードセットで実行されるようにします。 |
| 101 | +1. セキュリティ制約を提供する{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}を使用します。 |
| 102 | +1. Linuxノードでは、[AppArmor](/docs/tutorials/security/apparmor/)や[seccomp](/docs/tutorials/security/seccomp/)などのLinuxセキュリティモジュールを使用します。 |
| 103 | + |
| 104 | +### Runtime保護: ストレージ {#protection-runtime-storage} |
| 105 | + |
| 106 | +クラスターのストレージとそこで実行されるアプリケーションの保護のために、次のことができます: |
| 107 | + |
| 108 | +1. クラスターを、ボリューム保存時の暗号化を提供する外部ストレージプラグインと統合します。 |
| 109 | +1. APIオブジェクトの[保存時の暗号化](/docs/tasks/administer-cluster/encrypt-data/)を有効にします。 |
| 110 | +1. バックアップを使用してデータの耐久性を保護します。 |
| 111 | + 必要に応じていつでもこれらを復元できることを確認します。 |
| 112 | +1. クラスターノードとそれが依存するネットワークストレージ間の接続を認証します。 |
| 113 | +1. 自分自身のアプリケーション内でデータ暗号化を実装します。 |
| 114 | + |
| 115 | +暗号化キーについては、専用のハードウェア内で生成することで、漏洩リスクに対する最善の保護を提供します。 |
| 116 | +_ハードウェアセキュリティモジュール_ を使用すると、セキュリティキーを他の場所にコピーすることなく暗号化操作を実施できます。 |
| 117 | + |
| 118 | +### ネットワークとセキュリティ |
| 119 | + |
| 120 | +[ネットワークポリシー](/ja/docs/concepts/services-networking/network-policies/)や[サービスメッシュ](https://glossary.cncf.io/ja/service-mesh/)などのネットワークセキュリティ対策の検討もまた重要です。 |
| 121 | +Kubernetesの一部のネットワークプラグインは、仮想プライベートネットワーク(VPN)オーバーレイなどの技術を使用して、クラスターネットワークの暗号化を提供します。 |
| 122 | +設計上、Kubernetesはクラスターに独自のネットワークプラグインを使用することを許可しています(マネージドKubernetesを使用している場合、クラスターを管理している個人または組織がネットワークプラグインを選択している可能性があります)。 |
| 123 | + |
| 124 | +選択したネットワークプラグインとその統合方法は、転送中の情報のセキュリティに大きな影響を与える可能性があります。 |
| 125 | + |
| 126 | +### オブザーバビリティとランタイムセキュリティ |
| 127 | + |
| 128 | +Kubernetesを使用すると、追加のツールを使用してクラスターを拡張できます。 |
| 129 | +サードパーティのソリューションをセットアップすることで、アプリケーションと実行中のクラスターを監視またはトラブルシューティングするのに役立ちます。 |
| 130 | +Kubernetes自体にもいくつかの基本的なオブザーバビリティ機能が組み込まれています。 |
| 131 | +コンテナ内で実行されるコードは、ログの生成、メトリクスの公開、その他の可観測性データの提供ができます。 |
| 132 | +デプロイ時に、クラスターが適切な保護レベルを提供していることを確認する必要があります。 |
| 133 | + |
| 134 | +メトリクスダッシュボードやそれに類似するものをセットアップする場合、そのダッシュボードにデータを投入する一連のコンポーネントと、ダッシュボード自体を確認してください。 |
| 135 | +クラスターの機能が低下するようなインシデントが発生している場合でも信頼できるように、全体のチェーンが十分な回復力と整合性保護を備えて設計されていることを確認してください。 |
| 136 | + |
| 137 | +必要に応じて、(ログや監査レコードの忠実性を確保するのに役立つ)暗号化されたメジャーブートや認証された時間配分など、Kubernetes自体よりも下位のセキュリティ対策をデプロイしてください。 |
| 138 | + |
| 139 | +高い信頼性の環境のために、ログの改ざん防止と機密性を確保するために暗号化保護をデプロイしてください。 |
| 140 | + |
| 141 | +## {{% heading "whatsnext" %}} |
| 142 | + |
| 143 | +### クラウドネイティブセキュリティ {#further-reading-cloud-native} |
| 144 | + |
| 145 | +* クラウドネイティブセキュリティに関するCNCF[ホワイトペーパー](https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) |
| 146 | +* ソフトウェアサプライチェーンを保護するためのグッドプラクティスに関するCNCF[ホワイトペーパー](https://github.com/cncf/tag-security/blob/f80844baaea22a358f5b20dca52cd6f72a32b066/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) |
| 147 | +* [Fixing the Kubernetes clusterf\*\*k: Understanding security from the kernel up](https://archive.fosdem.org/2020/schedule/event/kubernetes/) (FOSDEM 2020) |
| 148 | +* [Kubernetes Security Best Practices](https://www.youtube.com/watch?v=wqsUfvRyYpw) (Kubernetes Forum Seoul 2019) |
| 149 | +* [Towards Measured Boot Out of the Box](https://www.youtube.com/watch?v=EzSkU3Oecuw) (Linux Security Summit 2016) |
| 150 | + |
| 151 | +### Kubernetesと情報セキュリティ {#further-reading-k8s} |
| 152 | + |
| 153 | +* [Kubernetesセキュリティ](/ja/docs/concepts/security/) |
| 154 | +* [クラスターの保護](/ja/docs/tasks/administer-cluster/securing-a-cluster/) |
| 155 | +* コントロールプレーンの[転送中のデータ暗号化](/docs/tasks/tls/managing-tls-in-a-cluster/) |
| 156 | +* [保存時のデータ暗号化](/docs/tasks/administer-cluster/encrypt-data/) |
| 157 | +* [KubernetesのSecret](/ja/docs/concepts/configuration/secret/) |
| 158 | +* [Kubernetes APIへのアクセスコントロール](/ja/docs/concepts/security/controlling-access) |
| 159 | +* Podの[ネットワークポリシー](/ja/docs/concepts/services-networking/network-policies/) |
| 160 | +* [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/) |
| 161 | +* [RuntimeClass](/ja/docs/concepts/containers/runtime-class) |
0 commit comments