コンテナやKubernetesの世界でますます高速化する継続的デリバリに、セキュリティは適応しなければならない、それにはコードとしてのセキュリティ(security as code)が必要だ、とMateo Bruillo氏は主張する。氏はRebelCon.io 2019で、継続的セキュリティを備えたDevSecOpsプロセスの実装方法について講演した。
人は1日に複数のビルドを合理的にレビューすることはできない。セキュリティの要件、制限、ベストプラクティスについて検討し、マイクロサービスをネイティブに理解するツールを使用して、それらを自動化するセキュリティチームが必要だ。DevOpsのアジリティと応答性を最大限に活用するには、アプリの全サイクルにおいてセキュリティが統合された役割を果たす必要がある。そのためにはセキュリティ・アズ・コードのアプローチを使用して、パイプラインにセキュリティを統合するべきだ、とBurillo氏は言う。
セキュリティをコードとして実装することのメリットとして、Burillo氏は、次のものを挙げている。
- まず初めに、最も重要なのは自動化だ。マイクロサービス/コンテナの世界をキャッチアップするためには、セキュリティプロセスを拡張し、高速化する必要がある。
- 可視性。すべてのチームメンバーがセキュリティルールにアクセスし、話し合うことによって、ノウハウのサイロ化を回避することができる。
- トレーサビリティ。変更の実施毎にバージョン管理と所有権を設定する。
コンテナはブラックボックスである。これは運用上は好都合だが、セキュリティには悪影響を及ぼす。問題が発見されるまで、数日あるいは数週間を要する場合もあるのだ。死体のない犯罪捜査のようなもので、セキュリティ侵害が発生した後、コンテナはおそらく消滅してしまう。
プロダクトにセキュリティを組み込む上で、間違いなくビルド時に行うべきステップは、CI/CDツールとイメージスキャナとの統合である。コンテナイメージスキャンはCVE(Common Vulnerabilities and Exposures、単に"脆弱性(vulnerabilies)"と呼ばれることもある)や脆弱性スキャンと関連付けられることが多いが、それは初歩に過ぎない、とBurillo氏は言う。高度なイメージスキャナを使ってできることは他にも、コンプライアンスチェック(NIST、PCI、MITRE)から、資格情報の漏洩検出、アプリケーションレベルでのセキュリティプラクティスの独自実装に至るまで、数多くある。
コンテナ特有のセキュリティコンプライアンス標準がいくつもあり、Kubernetesにはすぐに使用可能な優れたセキュリティ機能セットもあるのだから、車輪の再発明は避けるべきだ、とBurillo氏は言う。
現在最も一般的なユースケースは、Jenkins、AWS CI/CD、Bambooなど、CI/CDパイプラインとイメージスキャンソフトウェアの統合である。しかしBurillo氏は、それとは別の、より革新的だが必要性の低いユースケースを紹介した — ランタイムコンテナの定期的なイメージチェックを行うことだ。CI/CDによってイメージが"クリーン"であると定義された後、新たなゼロディ脆弱性が発見されたならば、あるいはコンテナが攻撃されてオリジナルの条件が変更されたならば、どうなるだろう？
イメージスキャンは必要だが十分ではない、とBurillo氏は言う。ランタイム時のセキュリティも必要なのだ。従来のLinuxセキュリティツールは、コンテナランタイムの可視性を提供していない。ツールセットを改める必要がある、と氏は提案する。
SysdigのテクニカルライターであるMateo Burillo氏に、RebelCon.io 2019での講演の後で話を聞いた。
InfoQ: セキュリティの世界でアジリティを実現するために、何ができるでしょうか？
Mateo Burillo: 重要な概念として採用できるのは、ITインフラストラクチャやQAで経験したものとそれほど変わりません — セキュリティ・アズ・コードの実現です。
セキュリティ・アズ・コードとはつまり、ルールをバージョン管理してリポジトリに保持する必要がある、という意味なのです。これらルールをセキュリティ運用チームがそのリポジトリにプッシュし、環境から動的にプルして適用できなければなりません。
概念を明確にするために、ひとつの例を挙げてみましょう。
例えば、Anchoreによるイメージスキャンを実装することで、コンテナイメージはCVEを検出するために常時スキャンされるようになります。次にセキュリティチームが、コンテナをルートとして実行したり、AWS資格情報をリークしたりしないことを決定します。
- セキュリティチームはスキャンポリシを変更して、新しいバージョンを内部リポジトリにプッシュします。
- Anchoreエンジンはこのような更新を検出し、ダウンロードし、適用するように記述されています。
- イメージの生成はCI/CDツール、例えばJenkinsが担当します。Anchoreの統合は簡単で、ビルドパイプラインのステップのひとつとして、このイメージスキャン検証が実行されます。Anchoreによって承認されたイメージのみが実際にJenkinsによって署名され、内部レジストリにプッシュされます。
- Kubernetesは、Admission Controllerを使用して、CI /CDツールによって署名されていないイメージの実行を拒否するように構成されています。
上記の例では、セキュリティチームはレベルの高いセキュリティ目標を設計するだけで、あとはすべて自動化されています。
InfoQ: コンテナ内で実行中のアプリケーションが安全に動作していることを確認するためには、何をすればよいのでしょう？
Burillo: ITには100％のセキュリティを保証できるものはありませんが、それを認識した上で、できる限りそれに近づけるためにできることはいくつかあります。
- イメージスキャン — 既知の脆弱性を検出し、自身のIT部門やデプロイするアプリケーションの種類に対して、より関連性の深いセキュリティのベストプラクティスに従います。例えば，
- アプリケーションに必要なのは外部ボリュームから
/web/htmlをマウントするだけである、ということが既知であれば、その他のDockerfile内のファイルシステム操作には危険フラグを立てる必要があります。- GLPv3とのライセンスの非互換性があります — そのようなライセンスを宣言してているソフトウェアパッケージがあれば、報告されなければなりません。
- コンテナ特有のセキュリティコンプライアンスフレームワークに対するコンテナの検証。"車輪を再発明しない"というのは、セキュリティの黄金律のひとつです。そのために標準があるのです。いくつか挙げると、
- NIST SP 800-190 アプリケーションコンテナセキュリティガイド
- CIS(Center for Internet Security) Kubernetesベンチマーク
- PCI DSS (Payment Card Industry Data Security Standard)
- コンテナの構築方法や実行時の動作について理解するには、深い可視性とトレーサビリティが必要です。目に見えないセキュリティの脅威を止めることはできません。
- ランタイムセキュリティルールと自動修復の実装。コンテナはシンプルなマシンです。動作が簡単に予測可能で、疑わしいものがあるかどうか、すぐに検出できます。これは実行時において大きなメリットとなります。この特徴を利用して、ITセキュリティを改善するのです。
InfoQ: Kubernetesにはどのようなセキュリティ機能があるのでしょう、それらを適用する際のアドバイスはありますか？
Burillo: 実にたくさんあります。しかも素晴らしい(最悪な？)ことに、その数は増え続けています — RBAC、アドミッションWebフック、ポッドセキュリティポリシ、ネットワークポリシ、自動証明書ローテーション、リソースクォータ ... というように。
私がアドバイスしたいのは、統計学者的に考える、ということです。必要以上に考えると、できる限り多くのルールを実装しようとする危険性があります。過去の攻撃から、開発者の経験から、エコシステムで悪評の高いセキュリティ侵害から、セキュリティ指向のKubernetesニュースレターやブログから、データを収集してください。その上で考えるのです。セキュリティを最大化し、複雑さを最小化するために、次に導入すべきセキュリティルールは何か？
その好例が、私たちがハニーポットとしてインターネットに公開した、脆弱性のあるKubernetesクラスタです。クラスタの欠陥は意図的なものですが、攻撃、攻撃検出、犯罪捜査は本物です。このようなセキュリティ侵害練習は、エコシステムにおける現実のアクティブな攻撃を特定して、それをブロックする上で役に立ちます。敵は常に変化し、適応していることに留意してください。セキュリティは軍拡競争なのです。
InfoQ: コンテナで実行されているソフトウェアの異常は、どうすれば検出できますか？
Burillo: 先程述べたように、コンテナの大きなメリットは、本質的に"シンプル"であるため、実行時に許可されるものと禁止されるものを決定するルールが容易に決定できる点です。一方で、大きなデメリットは、コンテナの登場前から存在していたセキュリティソフトウェアのほとんどが、ランタイムコンテナの動作を完全に見えなくしていることです — 入力と出力の解析は可能ですが、それ以外は完全なブラックボックスなのです。
ランタイムの異常検出には、いつもFalcoを推奨しています。コンテナを念頭に置いてゼロから設計されているため、カーネルレベルのインストルメンテーションを行うことで、完全な可視性とトレーサビリティが得られます。何よりも重要なのは、完全にオープンソースなCNCFサンドボックスプロジェクトである点です。今すぐ試してみることができますから、あなたのコンテナセキュリティルールをコミュニティに返して、コントリビュートしてください。