いまさらですがCloud Native Security Conference 2022の動画版を視聴しました。
名前のとおりCloud Nativeセキュリティについてホットなテーマが取り扱われていました。
event.cloudnativedays.jp
ここではNRIの方々が発表されていた内容を紹介します。
NRI:「サイバー攻撃を想定したクラウドネイティブセキュリティガイドラインとCNAPP及びSecurity Observabilityの未来」
こちらの発表ではクラウド、コンテナ、CICD、ソフトウェアサプライチェーンなど、クラウドネイティブを構成するインフラレイヤからアプリレイヤのセキュリティについて汎用的なガイドやアプローチを手広く紹介されています。
クラウドサービス、OS、ミドルウェアなどのインフラリソースは実装レベルの個別ガイドラインが並んでいます。アプリ層のガイドラインでは、OS、ミドルウェア、開発言語などの実装は問わず、クレジット情報を保護する、プライバシー情報を保護する、といったアプリで扱う情報資産の保護に注目しています。
クラウドセキュリティ
クラウドとは言ってもどこかにデータセンタ、物理サーバ、物理ネットワーク機器などは存在しますし、そのうえで動くOS、ミドルウェア、アプリの構成はオンプレと大差ありません。ただし、ビジネスモデルとしてそれらを管理する組織が異なるため、正しく役割分担をしておく必要があります。そこで、クラウド利用者とクラウドベンダの管理責任を分離する責任共有モデルがまず重要になります。特に、最近はIaaS、PaaS、SaaSのような一般的なモデルに加えて、サーバレス、ローコード、kubernetesなどの責任共有モデルも理解することが求められます。
あまり重要でないと思われる方もいるかもしれませんが、提案段階の上流工程でこれらが合意されないまま開発または運用時にトラブルが発生すると、対応方針や責任の所在が見当たらず困ります。例えば、「サーバレスサービスを使うぞ、セキュリティは後付けで考えるぞ」といったケースでは、「あれ?OSにアクセスできないのにアンチウィルス製品なんかインストールできないぞ?いつも使ってた脆弱性診断ツールがOSレイヤにアクセスできないと使えないぞ?」といったことが起こりえます。また、インシデントが発生した際に責任の合意が取れていないと「クラウド利用者もクラウドベンダも俺は悪くない」と言い張るようなことが起こります。
大多数のベンダはクラウドベンダが提供するクラウドサービスを利用する「クラウド利用者」の立場になると思われます。このとき、利用者側の責任範囲は問題ないのですが悩ましいのは「クラウドベンダの責任範囲」です。下記のように「SIerが他ベンダクラウドサービスを契約して顧客にシステムを納品するSI案件」でインシデントが起こった際のことを考えてみましょう。
もし、クラウドベンダ側の責任範囲に問題があったとしても、顧客はフロントでやり取りをしているSIer(クラウド利用者)の責任にしようとします。このとき、SIer(クラウド利用者)は「責任範囲じゃないので知りません」とはいえません。
クラウドベンダ→SIer(クラウド利用者)→顧客
クラウド利用者であっても、クラウドベンダの責任範囲は完全に無視していいというわけではなく、クラウドベンダで対策が取られていることを契約(合意)する「監督責任」が生じます。
ただ、スライドの説明にあるとおり、一問一答形式でクラウドベンダに確認していると膨大な時間がかかってしまいます。そこで、クラウドベンダが第三者認証として公開している範囲については満たされているとして、クラウド利用者側では最低限責任を追及できる状態を確保しておく、ということだと思います。
よく「Windows OSをセキュアにしてください」とか言われますが、具体的にどこをどう設定すればよいのかまで提示されないケースもよくあります。
また、コンポーネントによっては100項目を超えるような対策の実装を、開発者の知識や経験のみに頼るのは現実的ではありません。
そこで次のスライドでは、クラウドサービス、OS、ミドルウェアなど、いろんなレイヤの対策をどうすればいいのかという問いに対して、CIS Benchmarksを紹介しています。
CIS Benchmarksでは、幅広いコンポーネントに対して実装レベルかつセキュアな設定方法を提供しています。
このようなレギュレーションを採用すれば、開発者のスキルに依存することなくエンタープライズレベルで通用する堅牢化を実施することが可能です。
コンテナセキュリティ
コンテナについては少しライトな内容ですが、フルマネージドKubernetesの責任共有モデルやコンテナイメージの脆弱性スキャンについて言及されています。
フルマネージドKubernetesの責任共有モデルはややこしいので深く言及しませんが、CIS BenchmarksやAmazon EKS のベストプラクティス集などが参考になると思います。
Home - EKS Best Practices Guides
コンテナイメージの脆弱性診断ツールについては、未成熟な部分もあり注意が必要という内容です。
現在のコンテナイメージ脆弱性診断ツールは、「パッケージマネージャが管理する依存情報からパッケージ名やバージョンを抽出して脆弱性データベースと照合する」ような診断方式がとられています。そのため、「make installやwgetされた野良パッケージ」や「スキャン対象外のパッケージマネージャで管理されたパッケージ」は診断から漏れたりします。このような仕様を理解していないと思わぬ脆弱性が残ってしまいます。
運用監視
後半では、セキュリティバイデザイン(シフトレフト)やCICDなどを考慮して、セキュリティを効率的に組み込むツールを紹介されています。
SASTやDASTはアプリケーションの脆弱性、つまりセキュアコーディングができているかを自動チェックするツールになります。(SCAは違いますが)
そのほかにも、CSPM、CWPP、CIEMなどのクラウド環境保護製品が紹介され、それらがハッピーセットとなったCNAPP(Cloud-Native Application Protection Platform)が最強とされています。
たしかにこれさえ入れとけばOKといった製品が魅力的なのは間違いないですね。
この他にも関連技術や製品が紹介されていますので興味がある方は参照されてはいかがでしょうか。
