コンテナセキュリティの機能イメージ
コンテナセキュリティのベストプラクティスには、配信されるアプリケーションやコンテナイメージ自体だけでなく、コンテナのビルド、配布、特別な実行に使用されるコンポーネントスタック全体も含まれます。
これには以下が含まれます：
- ホストまたはVM
- コンテナのランタイム
- クラスター技術
- クラウドプロバイダーの構成
- などがあります。
それでは、一般的な考え方を、DevOpsのワークフローに適用できる18の具体的なコンテナセキュリティのベストプラクティスに分解しながら、興味深い詳細を見ていきましょう。
複雑なスタック
コンテナの成功は、2つの便利な機能によって支えられています。- コンテナは、従来のVMイメージよりもはるかに軽量でありながら、すべてのライブラリと依存関係を含む自己完結型の実行イメージとして、ソフトウェアを配布・実行するための非常に便利な方法です。
- カーネルネームスペースを使用して、マウント、PID、ネットワーク、IPCなどを含む独自の “jail “内でプロセスを実行することで、優れたレベルのセキュリティと分離を提供し、カーネルcgroupsを介してCPU使用量とメモリをリソース制限します。メモリ保護やパーミッションの適用などは、標準的なカーネルセキュリティメカニズムを介して行われます。
VMとコンテナの比較
ほとんどの場合、コンテナのセキュリティモデルで十分かもしれませんが、例えば、AWSはサーバーレスソリューションに追加のセキュリティを加えています。これは、Firecrackerというマイクロ仮想マシンの中でコンテナを実行することで実現しています。このマイクロ仮想マシンは、顧客間での侵入を防ぐために、もう一つのレベルの仮想化を追加します。
これはコンテナが安全ではないということなのでしょうか？
それは諸刃の剣だと言えます。
コンテナの中で動作するアプリケーションは、マシンの中で直接動作するアプリケーションと変わらず、他の多くのアプリケーションとファイルシステムやプロセスを共有しています。ある意味では、悪用可能な脆弱性を含む可能性のあるアプリケーションに過ぎません。
コンテナ内で実行すると、これを防ぐことはできませんが、アプリケーションのエクスプロイトからホストシステムにジャンプしたり、他のアプリケーションからデータにアクセスしたりすることが非常に困難になります。
一方で、コンテナは、別のカーネル機能、コンテナランタイム、そして通常はクラスターやオーケストレータに依存しており、これらも悪用される可能性があります。
そのため、スタック全体を考慮する必要があり、コンテナのライフサイクルのさまざまな段階でコンテナセキュリティのベストプラクティスを適用することができます。この2つの次元を以下の図に反映させ、各ブロックで適用できるプラクティスに焦点を当ててみましょう：
責任共有モデルで対応しています。
- プロバイダーは、ベースとなるピースの動作とセキュリティの維持に責任を持ちます。
- そして、あなたは上位レイヤーに集中することができます。
責任共有モデル
予防：シフトレフトセキュリティにおける8つのステップ
シフトレフトセキュリティ
コンテナ内のアプリケーションが実行される前に、脅威の発生を防ぐためのさまざまな技術を適用できる場所がいくつかあります。
予防とセキュリティの早期適用が重要であり、コンテナイメージの開発と配布時にいくつかのグッドプラクティスを適用すれば、最小限の労力で多くのトラブル、時間、コストを削減することができます。
1. CI/CDプロセスにコードスキャンを組み込む
セキュリティスキャンとは、ソフトウェア、構成、インフラを分析し、潜在的な問題や既知の脆弱性を検出するプロセスです。スキャンは、さまざまな段階で行うことができます。- コード
- 依存関係
- コードとしてのインフラ
- コンテナイメージ
- ホスト
- クラウド構成
- …などなど
name: "Security Scan"
on:
push:
jobs:
tests:
runs-on: ubuntu-latest
env:
GO111MODULE: on
steps:
- name: Checkout Source
uses: actions/checkout@v2
- name: Run Gosec Security Scanner
uses: securego/gosec@master
with:
args: ./...
そして、それに対応する出力：
2. 依存性スキャンによる外部脆弱性の低減
サードパーティ製のライブラリやフレームワークを使用しないのは、非常にミニマムでトイなアプリケーションだけです。しかし、外部の依存関係にあるコードを再利用することは、これらの依存関係にあるバグや脆弱性をアプリケーションの一部として含むことになります。依存関係のスキャンは、あらゆるアプリケーションのビルドプロセスにおいて、ベストプラクティスとして含めるべきです。 npm、maven、goなどのパッケージ管理ツールは、脆弱性データベースとアプリケーションの依存関係を照合し、有用な警告を提供することができます。 例えば、Mavenでdependency-checkプラグインを有効にするには、pom.xmlにプラグインを追加するだけです：<project>
...
<build>
...
<plugins>
...
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>6.2.2</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
...
</project>
そして、mavenが実行されるたびに、脆弱性レポートが生成されます：
依存関係にあるものを、修正を加えた新しいバージョンに更新することで、依存関係による脆弱性の導入を回避します。
依存関係のツリー
場合によっては、修正プログラムが利用できなかったり、バージョンを上げるには、破壊的な変更のために多くのリファクタリングが必要になったりするため、これができないこともあります。依存関係のスキャンによって明らかになった脆弱性を分析して、その影響度や悪用可能性を評価し、その脆弱性が悪用されるのを防ぐために、コード内のチェックや保護メカニズムなどの追加措置を導入します。
なお、依存関係を後からスキャンすることも可能ですが、アプリケーションがビルドされると、メタデータの情報が得られないものもあるため、依存関係のスキャンの精度は低くなります。また、GoやRustのように静的にリンクされたアプリケーションでは不可能な場合もあります。
3. コンテナイメージの分析にイメージスキャンを使用する
アプリケーションがビルドされ、パッケージ化されると、ライブラリ、依存するフレームワーク（Python、Nodeなど）、設定ファイルの最小限のセットを持つコンテナ内にコピーするのが一般的です。コンテナのビルドとランタイムに焦点を当てたベストプラクティスについては、「Dockerfileのベストプラクティス Top 20」をお読みください。 イメージスキャナーを使用してコンテナイメージを分析します。イメージスキャンツールは、コンテナイメージのベースディストリビューションが提供するオペレーティングシステムパッケージ（rpm、dpkg、apkなど）の脆弱性を発見します。また、前の段階で依存関係のスキャンを適用していなくても、Java、Node、Pythonなどのパッケージの依存関係にある脆弱性も発見されます。
イメージスキャンのスキーマ
イメージスキャンは、自動化と実施が容易です。CI/CDパイプラインの一部として組み込んだり、新しいイメージがレジストリにプッシュされたときにトリガーしたり、クラスターアドミッションコントローラーで検証して、非準拠のイメージの実行が許可されたことを確認したりすることができます。また、Sysdig Node Image Analyzerをインストールして、Sysdig Node Image Analyzerが稼働しているホストでイメージの実行が開始されると同時にスキャンするという方法もあります。
例としては、Sysdig Secure Inline Scan ActionとGithub Actionの統合があります。
name: "Security Scan"
on:
push:
jobs:
build-and-scan:
runs-on: ubuntu-latest
steps:
- name: Build the Docker image
run: docker build . --file Dockerfile --tag my-image:latest
- name: Scan image
id: scan
uses: sysdiglabs/scan-action@v3
with:
image-tag: my-image:latest
sysdig-secure-token: ${{ secrets.SYSDIG_SECURE_TOKEN }}
input-type: docker-daemon
run-as-user: root
前述の例では、Dockerイメージをビルドしてから、Dockerデーモンからローカルにスキャンしています。
スキャン結果はアクションの出力の一部として直接提供され、pull-requestはチェックステータスに応じてマージをブロックすることができます：
脆弱性をリストアップ
4. イメージコンテンツの信頼性確保
コンテナイメージの完全性は、Docker Notaryなどを介してデジタル署名を追加することで強制することができ、アドミッションコントローラーやコンテナランタイムで検証することができます。 簡単な例を見てみましょう：$ docker trust key generate example1 Generating key for example1... Enter passphrase for new example1 key with ID 7d7b320: Repeat passphrase for new example1 key with ID 7d7b320: Successfully generated and loaded private key. Corresponding public key available: /Users/airadier/example1.pub
$HOME/example1.pub秘密鍵は次の場所にあります：
$HOME/.docker/trust/private/<key ID>.key他の開発者も自分の鍵を生成し、公開部分を共有することができます。 それでは、許可された署名者の鍵をリポジトリに追加することで、署名付きリポジトリを有効にします（例ではairadier/alpine）：
$ docker trust signer add --key example1.pub example1 airadier/alpine Adding signer "example1" to airadier/alpine... Initializing signed repository for airadier/alpine... ... Enter passphrase for new repository key with ID 16db658: Repeat passphrase for new repository key with ID 16db658: Successfully initialized "airadier/alpine" Successfully added signer: example1 to airadier/alpineそして、リポジトリのイメージに署名することができます：
$ docker trust sign airadier/alpine:latest Signing and pushing trust data for local image airadier/alpine:latest, may overwrite remote trust data The push refers to repository [docker.io/airadier/alpine] bc276c40b172: Layer already exists latest: digest: sha256:be9bdc0ef8e96dbc428dc189b31e2e3b05523d96d12ed627c37aa2936653258c size: 528 Signing and pushing trust metadata Enter passphrase for example1 key with ID 7d7b320: Successfully signed docker.io/airadier/alpine:latest環境変数
DOCKER_CONTENT_TRUST が 1に設定されていれば、プッシュされたイメージは自動的に署名されます：
$ export DOCKER_CONTENT_TRUST=1 $ docker push airadier/alpine:3.11 The push refers to repository [docker.io/airadier/alpine] 3e207b409db3: Layer already exists 3.11: digest: sha256:39eda93d15866957feaee28f8fc5adb545276a64147445c64992ef69804dbf01 size: 528 Signing and pushing trust metadata Enter passphrase for example1 key with ID 7d7b320: Successfully signed docker.io/airadier/alpine:3.11イメージの署名者を確認するには、次のようにします：
$ docker trust inspect --pretty airadier/alpine:latest Signatures for airadier/alpine:latest SIGNED TAG DIGEST SIGNERS latest be9bdc0ef8e96dbc428dc189b31e2e3b05523d9... example1 List of signers and their keys for airadier/alpine:latest SIGNER KEYS example1 7d7b320791b7 Administrative keys for airadier/alpine:latest Repository Key: 16db658159255bf0196... Root Key: 2308d2a487a1f2d499f184ba...環境変数
DOCKER_CONTENT_TRUST が 1に設定されていると、Docker CLIは信頼情報のないイメージのプルを拒否します：
$ export DOCKER_CONTENT_TRUST=1 $ docker pull airadier/alpine-ro:latest Error: remote trust data does not exist for docker.io/airadier/alpine-ro: notary.docker.io does not have trust data for docker.io/airadier/alpine-roConnaisseurのようなアドミッションコントローラーを使うことで、Kubernetesクラスターでコンテンツの信頼性を確保することができます。
5. よくあるセキュリティの設定ミスと改善策
ホスト、コンテナランタイム、クラスター、クラウドのリソースが誤って設定されていると、攻撃への扉が開いたままになったり、特権を昇格させてラテラルムーブメントを行うための簡単な方法が生まれたりします。 ベンチマーク、ベストプラクティス、およびハードニングガイドでは、これらの誤設定を発見する方法、問題となる理由、および修正方法に関する情報を提供しています。様々な情報源の中でも、Center for Internet Security (CIS) は最も重要です。非営利団体であるCISは、様々な環境のベンチマークを無料で公開しており、個人や企業がその知識を活かしてコントリビュートすることができます。これは、セキュリティベンチマークのデファクトスタンダードとなっています。 コンテナのセキュリティに関するこのような設定を確実にチェックするには、できるだけ自動化するのが一番です。そのためのツールがいくつか存在し、主に静的な設定分析をベースに、さまざまなレベルの設定パラメータをチェックし、修正のガイダンスを提供することができます。 Sysdig Secureには、コンプライアンス＆ベンチマーク機能があり、CISベンチマークをはじめ、PCI DSS、SOC 2、NIST 800-53、NIST 800-190、HIPAA、ISO 27001、GDPRなどのコンプライアンス基準に基づいて、すべてのインフラ（Linuxホスト、Docker、Kubernetes、EKS、GKE、Openshiftクラスターなど）をスケジュール、実行、分析することができ、すべてを1つの集中ダッシュボードで行うことができます。
Sysdigのセキュアダッシュボード
他にも、linux-bench、docker-bench、kube-bench、kube-hunter、kube-striker、Cloud Custodian、OVAL、OS Queryなどのツールを利用することができます。
ホストベンチマークコントロール例
Linuxをインストールしたばかりの物理マシン、クラウドプロバイダーでプロビジョニングされた仮想マシン、またはオンプレミスの仮想マシンには、あなたが気付いていない安全でないアウトオブボックスの設定がいくつか含まれている可能性があります。長期間、本番環境で使用したり、インターネットに接続したりする場合は、特に注意しなければなりません。これはKubernetesやOpenShiftのノードにも言えることです。クラウドプロバイダーがプロビジョニングしたクラスターを使用しているからといって、そのクラスターが完全に保護されているとは思わないでください。 CISでは、ディストリビューションに依存しないLinuxのベンチマークを用意しており、Debian、CentOs、Red Hatなど多くのディストリビューションに対応しています。 検出できる設定ミスの例：Linuxディストリビューションの例
次の図は、CIS Benchmark for Distribution Independant Linuxで提供されているもので、rshサーバが有効になっていないことを確認するための設定です。
コンテナランタイムのベンチマークコントロールの例
Dockerのようなコンテナランタイムを自分で所有するサーバにインストールする場合、ベンチマークを使ってデフォルトの安全でない構成が改善されていることを確認することが不可欠です。次の図は、Dockerクライアントコマンドの認証が有効になっていることを確認するための設定です。
オーケストレーターベンチマークコントロールの例
Kubernetesは、デフォルトでは、多くの認証メカニズムをサードパーティの統合によって管理するようになっています。ベンチマークにより、考えられるすべての不安要素に対処することができます。下の画像は、-anonymous-auth引数がfalseに設定されていることを確認するための設定を示しています。
クラウドベンチマークコントロールの例
クラウドプロバイダーのアカウントにおけるベンチマークは、CSPM（Cloud Security Posture Management）とも呼ばれ、アカウント上のすべての資産のセキュリティをチェックするため、必要不可欠なものです。攻撃につながる可能性のある設定や、プライベートであるべきなのに公開されているリソース（S3バケットなど）、暗号化されていないストレージなどはすべてこのようなベンチマークで定義されます。クラウドアカウントの資産は常に変化しており、すべてが可能な限り安全であることを常に監視しなければならないため、これは自動化が必須のベンチマークです。次の画像は、90日以上使われていない認証情報が無効になっていることを確認する設定チェックの例です。
6. IaCスキャンの導入
クラウドのリソース管理は複雑な作業であり、TerraformやCloudFormationなどのツールはこの負担を軽減してくれます。インフラはコードとして宣言され、別名「Infrastructure as Code」として、リポジトリに保存され、バージョン管理されます。そして、定義の変更を適用して、既存のインフラを宣言に合わせて最新の状態にすることは、自動化によって行われます。 コードとしてのインフラストラクチャーを使用している場合、Apolicy、Checkov、tfsec、cfn_nagなどのIaCスキャンツールを組み込んで、インフラストラクチャーを作成または更新する前にその構成を検証します。他のリンティングツールと同様に、IaCスキャンツールをローカルおよびパイプラインに適用し、セキュリティ上の問題を引き起こす変更をブロックすることを検討してください。 checkovの実行例です：$ pip install checkov
$ checkov --quiet -d .
_ _
___| |__ ___ ___| | _______ __
/ __| '_ \ / _ \/ __| |/ / _ \ \ / /
| (__| | | | __/ (__| < (_) \ V /
\___|_| |_|\___|\___|_|\_\___/ \_/
By bridgecrew.io | version: 2.0.346
terraform scan results:
Passed checks: 314, Failed checks: 57, Skipped checks: 0
Check: CKV_AWS_108: "Ensure IAM policies does not allow data exfiltration"
FAILED for resource: aws_iam_policy_document.cloudtrail_ingestor
File: /modules/ingestor/main.tf:17-31
Guide: https://docs.bridgecrew.io/docs/ensure-iam-policies-do-not-allow-data-exfiltration
17 | data "aws_iam_policy_document" "ingestor" {
18 | statement {
19 | effect = "Allow"
20 | actions = [
21 | "s3:Get*",
22 | "s3:List*",
23 | "s3:Put*",
24 | "s3:Head*",
25 | "sqs:DeleteMessage",
26 | "sqs:DeleteMessageBatch",
27 | "sqs:ReceiveMessage",
28 | ]
29 | resources = ["*"]
30 | }
31 | }
...
7. ホストスキャンによるホストの保護
ホストを保護することは、コンテナを保護することと同様に重要です。コンテナが実行されるホストは、通常、Linuxカーネル、一連のライブラリー、コンテナランタイム、その他の一般的なサービスやヘルパーがバックグラウンドで動作するオペレーティングシステムで構成されています。これらのコンポーネントには脆弱性や設定ミスがある可能性があり、実行中のコンテナにアクセスするためのエントリーポイントとして使用されたり、サービス拒否攻撃を受けたりする可能性があります。 例えば、今回のDoS攻撃のように、コンテナランタイム自体に問題があると、ホスト内で新しいコンテナを作成できなくなるなど、稼働中のコンテナに影響が出てしまうことがあります。 ホストの構成を強化することについては、「安全でない構成」のセクションですでに説明しました。しかし、脆弱なコンポーネントをどのようにして検出するのでしょうか。ホストスキャンツールは、カーネル、glibcなどの標準ライブラリ、サービス、さらにはホスト内のコンテナランタイムに存在する既知の脆弱性を検出することができます（コンテナイメージに対してイメージスキャンが行うのとよく似ています）。 Sysdig Host Analyzerは、ホストを透過的にスキャンし、発見された脆弱性をレポートします。 次の図は、ダッシュボード上で一目でリスクを検出することができることを示しています。
この情報を使って、OS、カーネル、パッケージなどをアップデートします。最も重要で悪用されやすい脆弱性を取り除くか、少なくともそれを認識し、ファイアウォール、ホストへのユーザーアクセスの制限、使用されていないサービスの停止など、他の保護メカニズムを適用してください。
8. 安全でないコンテナの実行を防ぐ
最終的な防御策として、Kubernetes Admission Controllerは、安全でないコンテナがクラスター内で実行されるのをブロックすることができます。 Sysdig アドミッションコントローラーでは、スキャン結果に基づいて、セキュリティポリシーに合格しないイメージを実行しているポッドの作成を拒否することができます。 Gatekeeperには強力な言語が用意されており、ポッドの仕様（アノテーションの強制、特権ポッドの検出、ホストパスの使用など）やクラスターの状態（すべてのingressホストがクラスター内でユニークであることを要求するなど）に基づいて、コンテナの受け入れや拒否を行う柔軟なルールを定義することができます。 例として、以下のGatekeeper ConstrainsTemplate (一部のデータは省略されています)は、必要なアノテーションを検出するためのテンプレートを定義しています。apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8srequiredannotations
annotations:
description: Requires all resources to contain a specified annotation(s) with a value
matching a provided regular expression.
spec:
...
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8srequiredannotations
violation[{"msg": msg, "details": {"missing_annotations": missing}}] {
provided := {annotation | input.review.object.metadata.annotations[annotation]}
required := {annotation | annotation := input.parameters.annotations[_].key}
missing := required - provided
count(missing) > 0
msg := sprintf("you must provide annotation(s): %v", [missing])
}
violation[{"msg": msg}] {
value := input.review.object.metadata.annotations[key]
expected := input.parameters.annotations[_]
expected.key == key
expected.allowedRegex != ""
not re_match(expected.allowedRegex, value)
msg := sprintf("Annotation <%v: %v> does not satisfy allowed regex: %v", [key, value, expected.allowedRegex])
}
このテンプレートを使用して、すべてのサービスがいくつかのアノテーションを持つことを強制することができます：
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredAnnotations
metadata:
name: all-must-have-certain-set-of-annotations
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Service"]
parameters:
message: "All services must have a `a8r.io/owner` and `a8r.io/runbook` annotations."
annotations:
- key: a8r.io/owner
# Matches email address or github user
allowedRegex: ^([A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}|[a-z]{1,39})$
- key: a8r.io/runbook
# Matches urls including or not http/https
allowedRegex: ^(http:\/\/www\.|https:\/\/www\.|http:\/\/|https:\/\/)?[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,5}(:[0-9]{1,5})?(\/.*)?$
他にもたくさんの例が、OPA Gatekeeperライブラリープロジェクトで公開されています。
コンテンツの信頼性を確保し、信頼できるソースから署名されていないイメージを拒否する方法として、Connaisseur Admission Controllerを紹介しました。
プロテクション – コンテナを安全に稼働させる
ビルド時や構成時のコンテナセキュリティのベストプラクティスをランタイムの直前まで遵守しても、コンテナを100％安全にすることはできません。コンテナの新しい脆弱性は日々発見されているため、現在は安全な実際のコンテナも、明日には新たに公開されたエクスプロイトの被害者になる可能性があります。
このセクションでは、コンテナの脆弱性管理と保護対策をワークロードに組み込むための、コンテナセキュリティのベストプラクティスを紹介します。
9. リソースの保護
お使いのコンテナやホストには脆弱性が含まれているかもしれませんし、新しい脆弱性は絶えず発見されています。しかし、危険なのはホストやコンテナの脆弱性そのものではなく、攻撃ベクトルや悪用可能性にあります。 例えば、ネットワークを悪用できる脆弱性の場合、実行中のコンテナや脆弱なサービスへの接続を妨げることで防御することができます。また、攻撃ベクトルがホストへのローカルアクセス（ホストにログインしていること）を必要とする場合、そのホストへのアクセスを制限することができます。 そこで、ホストやクラウドアカウント、リソースにアクセスできるユーザー数を制限し、さまざまな仕組みを使って不要なネットワークトラフィックを遮断します。- VM、VPC、インターネット間の通信を制限するために、クラウド事業者ではVPC、セキュリティグループ、ネットワークルール、ファイアウォールルールなどがあります。
- ホストレベルのファイアウォールでは、必要最小限のサービスのみを公開します。
- クラスターにはKubernetesのネットワークポリシーを適用し、Service MeshやAPI Gatewayなどのツールを追加することで、ネットワークリクエストをフィルタリングするための追加のセキュリティレイヤーを追加することができます。
10. イメージ署名の検証
イメージコンテンツの信頼性で述べたように、イメージ署名は、イメージが改ざんされていないことを保証する保護メカニズムです。また、イメージ署名を検証することで、タグが発行者によって署名された特定のダイジェストに対応していることを保証し、タグの可変型攻撃の一部を防ぐことができます。下図はこの攻撃の一例です。
11. ランタイム時にコンテナの権限を制限する
コンテナ内で悪用された脆弱性の範囲または「爆発半径」は、コンテナの権限と、ホストや他のリソースからの隔離レベルに大きく依存します。ランタイム時の設定は、以下の方法で既存および将来の脆弱性の影響を軽減することができます。- 有効なユーザー：コンテナを root として実行しない。さらに良いのは、ホスト内の実際のユーザーにマッピングされないランダムなUID（Openshiftのような）を使用するか、DockerやKubernetesのユーザーネームスペース機能を準備ができ次第使用することです（本記事公開時には利用できていません）。
- コンテナの権限を制限する：DockerとKubernetesは、能力を落とす方法を提供し、特権的なコンテナを許可しません。SeccompとAppArmorは、コンテナが実行できるアクションの範囲にさらに制限を加えることができます。
- リソース制限を追加する：コンテナがすべてのメモリやCPUを消費して、他のアプリケーションが飢えてしまうことを避ける。
- 共有ストレージやボリュームに注意する：具体的には、hostPath のようなもので、ホストからのファイルシステムを共有します。
- hostNetwork、hostPID、hostIPCなどの他のオプション：Kubernetesはコンテナがホストとネームスペースを共有し、隔離性を低下させます。
- Pod Security Policies（PSP）とSecurity Context Constraints（OpenshiftではSCC）を定義する：クラスターにガードレールを設定し、コンテナの設定ミスを防ぎます。PSPとSCCはアドミッションコントローラーで、セキュリティコンテキストが定義されたポリシーに準拠していない場合にポッドを拒否します。
12. コンテナの脆弱性を賢く管理する
脆弱性を賢く管理・評価しましょう。すべての脆弱性に修正プログラムが用意されているわけではありませんし、今なら簡単に適用できるかもしれません。 しかし、すべての脆弱性が簡単に悪用できるとは限りませんし、悪用するためにはホストへのローカルまたは物理的なアクセスが必要な場合もあります。 など、しっかりとした戦略を立てる必要があります：- 修正すべきものの優先順位をつける：ホストやコンテナの脆弱性のうち、スコアや深刻度が高いものに焦点を当てるべきです。これは、リモートから悪用可能であり、公開されたエクスプロイトが利用可能であることを意味することが多いです。脆弱性が古くてよく知られている場合は、自動化された方法で積極的に悪用されている可能性が高くなります。
- あなたの環境における脆弱性の深刻度を評価してください：ベンダーや使用しているLinuxディストリビューションが提供するスコアや深刻度は良い出発点です。しかし、脆弱性がリモートから悪用可能で、インターネットにさらされていない内部ホストの未使用のパッケージに存在する場合、その脆弱性は高いスコアを得ることができます。そして、それは本番環境でも、開発者の遊び場や実験用のクラスターでも構いません。状況に応じて影響を評価し、それに応じた計画を立てましょう。
- コンテナやホストを保護するための対策として、修正プログラムの適用を計画します：チケットを作成して追跡し、脆弱性管理を標準的な開発ワークフローの一部にしましょう。
- 影響がないと判断した場合は、脆弱性の例外を作成する：これにより、ノイズを減らすことができます。例外を恒久的に追加するのではなく、スヌーズを検討し、後で再評価できるようにします。
- チケッティング：検出された脆弱性を開発者に通知し、開発者が修正プログラムを適用できるようにする。
- イメージレジストリ：脆弱性のあるイメージが全て引き出されないようにする。
- ホスト / カーネル / コンテナ：ランタイム中のコンテナをブロックしたり、保護手段を追加したり、重大な問題が発生したホストやコンテナをKill、隔離、シャットダウンして対応する。
検出 – 異常な振る舞いに対するアラート
ここまでは、予防と保護に焦点を当て、コンテナを可能な限り最高の状態で稼働させ、潜在的な攻撃や既知の攻撃を予測してきました。コンテナのビルド、配布、ランタイム時に予防技術を適用して、正しい権限と保護機能を持たせたり、基盤となるスタックを確保したりすることで、攻撃者の行動範囲を制限することができます。しかし、だからといって、コンテナの実行を忘れて、適用されたセキュリティ対策を信用することはできません。セキュリティ対策が実行されると、攻撃される可能性が出てきます。是正措置を講じてセキュリティインシデントの再発を防ぐためには、アプリケーションの異常な動作や予期せぬ動作を検知する必要があります。
さまざまな攻撃ベクターが存在します。例えば、MITRE ATT&CK は、「実世界での観察に基づく」戦術と技術の広範なリストを提供しており、これを使用して防止策を適用することも、活動を分析して攻撃や侵入が行われていることを意味する異常な動作を検出することもできます。MITRE ATT&CK Matrix for Containersは、特にコンテナ技術を対象とした技術をカバーしています。
Mitre Schema
13. リアルタイムのイベントおよびログ監査のセットアップ
コンテナセキュリティへの脅威は、さまざまなログやイベントのソースを監査し、異常なアクティビティを分析することで検出できます。イベントのソースには次のようなものがあります。- ホストおよびKubernetesのログ
- クラウドログ（AWSのCloudTrail、GCPのActivity Auditなど）
- コンテナ内のシステムコール
rule: ECS Task Run or Started condition: aws.eventSource="ecs.amazonaws.com" and (aws.eventName="RunTask" or aws.eventName="StartTask") and not aws.errorCode exists output: A new task has been started in ECS (requesting user=%aws.user, requesting IP=%aws.sourceIP, AWS region=%aws.region, cluster=%jevt.value[/requestParameters/cluster], task definition=%aws.ecs.taskDefinition) source: aws_cloudtrail description: Detect a new task is started in ECS.また、Sysdigは、対応するコンプライアンス標準とコントロールでタグ付けされた増え続けるルールのセットを含み、インフラストラクチャーのすべてのセキュリティイベントを調査するための一元化されたダッシュボードを提供しています。
14. リソースの監視
過剰なリソース使用量（CPU、メモリ、ネットワーク）、使用可能なディスク容量の急激な減少、平均以上のエラーレート、遅延の増加などは、システムで何か異変が起きていることを示すシグナルかもしれません。 Prometheusのようにメトリクスを収集してください。値が予想されるしきい値を超えたときに、すぐに通知されるようにアラートを設定します。意味のあるダッシュボードを使用して、メトリクスの変化を調べ、他のメトリクスの変化やシステムで発生しているイベントと関連付けることができます。
Sysdigモニターのメトリクス
この例では、リクエストレイテンシーが急激に増加し、リクエストレートが低下していることがわかります。これは、コンテナ内で何かが起こっていることを意味しています（例えば、クリプトマイナーが利用可能なCPUをすべて消費しているなど）。または、レスポンスの低下や潜在的なDoSを引き起こすエクスプロイトがあることを意味しています。同時期に発生した関連するクラスターイベントを確認すると、ポッドが交換されているので、悪意のあるバージョンや単に設定が間違っているバージョンがデプロイされた可能性もあります。
インシデント対応とフォレンジック
システムでセキュリティインシデントが発生していることを検知したら、脅威を止め、さらなる被害を抑えるために行動を起こします。単にコンテナを停止したり、ホストをシャットダウンしたりするのではなく、コンテナを隔離したり、一時停止したり、スナップショットを取ったりすることを検討します。優れたフォレンジック分析は、多くの手がかりを提供し、何が、いつ、どのように起こったかを明らかにします。特定することが重要です。
- そのセキュリティインシデントが実際の攻撃なのか、それとも単なるコンポーネントの誤動作なのか。
- 具体的に何が起こったのか、どこで発生したのか、影響を受ける可能性のあるコンポーネントは他にあるのか。
- どのようにしてセキュリティインシデントの再発を防ぐことができるか。
15. 隔離と調査
セキュリティインシデントが検出されたら、それ以上の被害を抑えるために、まず迅速に停止させる必要があります。- 停止とスナップショット： 可能な限り、ホストやコンテナを隔離します。コンテナのランタイムが提供するのは、コンテナを「一時停止」するか（「docker pause」コマンドなど）、スナップショットを取ってから停止することでした。ホストの場合は、ファイルシステムレベルでスナップショットを取ってから停止させることが考えられます。EC2やVMインスタンスの場合は、インスタンスのスナップショットを取ることもできます。その後、隔離に進みます。スナップショットを、ネットワークのない安全なサンドボックス環境にコピーして、ホストやコンテナを再開することができます。
- 探索とフォレンジック： 隔離が完了したら、理想的にはライブのコンテナやホストを探索して、実行中のプロセスを調査します。ホストやコンテナが生きていない場合は、ファイルシステムのスナップショットに注目してください。ログや変更されたファイルを調査します。Sysdig Secure captures のように、イベント発生時のシステムコールをすべて記録することでフォレンジック機能を大幅に強化するツールがありますので、コンテナやホストが死んだ後でも調査することができます。
- 最後の手段として、侵害されたコンテナやホストを破壊します：疑わしいアクティビティを破壊するだけで、短期的にはさらなる被害を防ぐことができます。しかし、何が起こったのか詳細がわからないと、再発を防ぐことができません。また、次の攻撃が起こるのを待って、再びKillすることを繰り返すという、終わりのないモグラ叩きのような状況に陥る可能性があります。
16. 設定ミスの修正
調査では、攻撃を可能にした原因を明らかにする必要があります。攻撃原因が判明したら、再発防止のためのセキュリティ対策を行いましょう。ホスト、コンテナ、アプリケーションが危険にさらされる原因は、過剰なパーミッション、露出したポートやサービスなどの悪い設定、または悪用された脆弱性の場合があります。 前者の場合は、誤った設定を修正して、二度と起こらないようにします。後者の場合は、ファイアウォールなどの設定を変更したり、より制限の厳しいユーザーを使用したり、追加のパーミッションやACLなどでファイルやディレクトリを保護したりすることで、脆弱性が悪用されるのを防ぐ（あるいは少なくともその範囲を制限する）ことができるかもしれません。 この問題が環境内の他の資産にも適用される場合は、すべての資産に修正プログラムを適用してください。特に、リモートネットワーク接続を介してエクスプロイトを実行できる場合には、インターネットからアクセス可能なアプリケーションなど、公開される可能性があるものについては、修正を行うことが重要です。17. 脆弱性へのパッチ
可能な限り、脆弱性そのものを修正してください：- オペレーティングシステムのパッケージ（dpkg、rpmなど）の場合：まず、配布ベンダーが修正プログラムを含むパッケージの更新版を提供しているかどうかを確認してください。パッケージまたはコンテナのベースイメージを更新してください。
- 古いディストリビューションのバージョン：ベンダーが更新版やセキュリティフィックスの提供を停止します。手遅れになる前に、ホストやイメージをサポートされたバージョンにしておきましょう。
- NodeJS、Go、Javaなどの言語パッケージの場合：依存関係の更新バージョンをチェックします。大きなバージョンの更新で起こりうる破壊的な変更の計画やテストに時間をかけられない場合は、セキュリティ問題を修正するだけのマイナーアップデートやパッチバージョンを探しましょう。しかし、古いバージョンが永遠に維持されるわけではありませんので、事前に計画を立ててください。
- ディストリビューションがパッチ版を提供していない場合や、保守されていないパッケージの修正プログラムがない場合：修正プログラムが存在する可能性もあり、手動で適用したりバックポートしたりすることができます。これにはいくつかの追加作業が必要になりますが、システムにとって重要なパッケージや、公式の修正版がまだ存在しない場合には必要になることがあります。NVDのようなデータベースの脆弱性リンク、ベンダーのフィードやソース、バグレポートの公開情報などをチェックします。修正プログラムが提供されていれば、それを見つけることができるはずです。
18. ループを閉じる
残念ながら、ホストとコンテナのセキュリティは、一連のセキュリティコンテナのグッドプラクティスを一度適用するだけで永遠に忘れることができるような一方通行のものではありません。ソフトウェアやインフラは日々進化しているため、複雑さが増し、新たなエラーが発生します。これは、脆弱性や構成上の問題につながります。また、新たな攻撃や悪用方法も絶えず発見されています。 まずは予防とセキュリティのベストプラクティスを盛り込むことから始めましょう。そして、ホストやワークロードだけでなく、クラウドサービスも含めたリソースに保護対策を施します。監視を継続し、異常な動作を検出して、発見されたインシデントに対処、対応、調査、報告します。フォレンジックの証拠があれば、発見された脆弱性を修正し、保護対策を改善して、イメージの再ビルド、パッケージの更新、リソースの再設定を行い、将来のセキュリティインシデントに備えてインシデントレポートを作成する、というループを閉じることができます。 中間では、リスクを評価し、脆弱性を管理する必要があります。複雑で大きな環境で管理すべきインプットの数は圧倒的に多いので、分類して優先順位をつけ、最もリスクの高いものから集中的に管理します。
まとめ
コンテナセキュリティのベストプラクティスが、DevOpsのワークフローに簡単に適用できることを確認しました。特に、以下のことを覚えておいてください：- シフトレフトセキュリティ、最初のステップは予防です。
- すべての資産を守ること。
- 組織内で起こっていることをすべて把握し、問題を可能な限り迅速に監視・検出する。
- 攻撃は避けられないので、インシデント対応を計画する。
Sysdig Secureは、これらのコンテナセキュリティのベストプラクティスに従うことを支援します。脆弱性や設定ミスをチェックすることで、セキュリティをシフトレフトさせ、脅威が展開される前に行動できるようになります。わずか数分で設定が完了します。今すぐお試しください！