以前からCloud-NativeアプリケーションのTop 10ページが存在することは知っていたのですが、ほとんどがTBDなのでなんだろうと思ってたんです。
今見たら内容の入っているTop 10記事ができていました。まだレビュー中のようです。

日本語訳あります。

そもそもCloud-Native Applicationってなんだ

コンテナ技術を活用して動いているアプリケーション、くらいで考えていただくと良いと思います。

Amazonの説明によるとコンテナオーケストレーション上で動くマイクロサービスアーキテクチャのアプリケーション、という定義になっています。間違いではないです。コンテナオーケストレーションを使った場合、モノリシックな大きなアプリケーションだとメリットが薄いため相性が悪いのは事実なので。

CNAS-1: 安全でないクラウド、コンテナ、オーケストレーションの構成

rootとして実行しているコンテナやホストとネットワークインターフェースなどのリソースを共有しているコンテナなど。
クラウド環境、コンテナ、オーケストレーションのインフラ的なお作法は守りましょう。

NCAS-2: インジェクションの欠陥 (アプリ層、クラウドイベント、クラウドサービス)

SQLインジェクションやスクリプトインジェクションなど。

サーバーレスイベントデータインジェクションは従来型システムとしては存在しなかったですね。
現在マイクロサービスアーキテクチャかどうかに関わらず、Kafkaのようなイベント連携をベースとする非同期連携基盤を使う場合には気にした方が良い内容です。
またKafkaを使っていなくとも、イベント (どこかで発生した事象) を伝達し合うような実装をしている場合はやはり気にした方が良い内容です。

例えば以下の図をご参照ください。

画像一番左、社食システムの方では決済端末から決済履歴マイクロサービスはAPIで連携しているとします。
決済履歴マイクロサービスから人事システム側の2つのマイクロサービスへは非同期メッセージング基盤であるKafkaを使ってPub/Subで連携しているとします。

ではこの状況で、一番左側にある決済端末側がなんらかの形で乗っ取られ、例えばDB操作を不正に行うSQLや、コンテナのローカルを参照して秘密情報を抜き出すようなOSコマンドが不正に挿入された状態で決済端末に書き込みリクエストが来たらどうでしょうか。
非同期連携基盤を通じて人事側の端末にまでSQLやOSのコマンドを届けることにならないでしょうか。

明らかにAPIなどで公開されている情報からのインプットはデータのサニタイズなどを行うことが多いものの、意外とシステム間連携は「受け取ったところがサニタイズしているだろうから」と守りが緩くなりがちです。
Subscribe側もおかしなデータが紛れ込んでいないか、忘れずにチェックしてください。

参考情報

こちらはイベントインジェクションをStep by Stepで説明してくれるページ。

記事からリンクされている講演動画。イベントインジェクションの概念の説明などはこちらが詳しいです。

また以下のServerless Application Security Top 10の解説のうち、SAS-1のFunction Event-Driven InjectionがこのCNAS-2に該当しますので、合わせてお読みいただくと良いかと思います。

CNAS-3: 不適切な認証と認可

アクセス権管理が面倒なので広い範囲でついつけてしまいたくなりがちですが、不用意にアクセス権を広い範囲につけるのは避けましょう！

CNAS-4: CI/CDパイプラインとソフトウェアサプライチェーンの欠陥

例えばコンテナなどを利用する場合のイメージは信用できるかどうか。
オンラインで見つかったツールを活用してCI/CDパイプラインを構築する場合、このツールは信頼できるか。
パイプラインを構築する時のツール群は精査が甘くなりがちなので、そこを狙った攻撃が増えているそうです。

参考情報

非常にわかりやすいソフトウェアサプライチェーンの解説

ソフトウェアサプライチェーンへの攻撃についてはこの説明が非常にわかりやすい。

CNAS-5: 安全でないシークレットの保存

各種シークレットは安全な場所に見えないようにおきましょう！

Aマイクロサービスがあるとします。
AマイクロサービスはBのAPIサービスを使っています。接続のためにIDとシークレットが必要です。
ではこれはどこに格納しますか？

これをコンテナのローカルのどちらかに平文でおく、あるいはコードのどちらかに平文で書くなどでAPIのアクセス情報が抜き出されてしまいます。

特にマイクロサービスアーキテクチャの環境では各種のソリューションを使うことが想定されます。
そういったものが認証をきちんとかけていることでアクセス権管理を厳密にできるメリットもありますが、接続元側の秘密情報管理が甘いと、万が一ローカルアクセスが実現してしまった時に抜き出されて利用されてしまいますので、万が一の侵入対策をしておきましょう。

CNAS-6: 過度に寛容または安全でないネットワークポリシー

コンテナオーケストレーションや仮想サーバーの環境などは、ネットワーク部分をうまく仮想化できるので、より閉じたネットワークをうまく作れると思うんです。
そういった閉じたネットワークのメリットを活用し、セキュアなネットワークを実現しましょう！

個人的にこちらには衝撃を受けました。

マイクロサービスに実装されたAPIをそのまま外部からつつけるようにせず、API Gatewayなどのセキュリティ機能を通してしか繋がらないようにしてください。

CNAS-7: 既知の脆弱性を持つコンポーネントの使用

パッチは適用しましょう！

これは余談ですが、OSSを使用することのリスクが懸念される領域はここだと思います。
OSSでの開発が活発であればパッチも早々に出るのですが。

ベンダーロックインを忌避する組織は多く、お気持ちはよくわかりますが、OSSを選択されるのであればシステムを塩漬けしない、定期的に採用している技術を見直し、コミュニティの人数が減って来たなどで脆弱性対応にリスクがあるのであれば置き換える覚悟が必要かなと思います。

経産省からOSSについてのレポートが出ていますね。非常に良い内容ですのでリンクしておきます。

OSS の利活用及びそのセキュリティ確保に向けた管理手法に関する事例集

CNAS-8: 不適切な資産管理

昔サービスマネジメントの講演会に参加した時に、CMDBがきちんと管理されていなかったため、サーバーの棚卸しをしたら本来あるべきサーバー台数の何倍もまだラックに置いてあり、誰も利用していない過去のアプリケーションが稼働して電気代を食っていたと言う話を聞いたことがあります。

このように、我々リリースすることには必死になるんですが、リタイアさせることは忘れてたりしますよね。

クラウドネイティブな環境でリタイア忘れが発生すると、本番環境にはまだ存在するものの、扱いとしてはリタイア済みのためドキュメントからは削除されて忘れ去られており、パッチが当たっていなかったり、アプリケーションレベルの不備などが修正されずに放置されて狙われるということが発生します。

CNAS-9: 不適切なコンピュートリソースクォータ制限

例えばAPIの流量制御をしていない、コンテナに割り当てできるリソースの上限を設定していないなどです。
コンピューティングリソースを制約なく使うとリソース枯渇が発生しやすくなり、サービスの可用性に直接的な影響がありますね。

CNAS-10: 無効なログ記録と監視 (ランタイムアクティビティなど)

実行環境のモニタリングやログが不十分な場合。

文章やOWASPのTop 10ページだけ見るとAvailabilityの話のような印象を受けますが、もっと幅広く、対応すべきセキュリティインシデントが検知できていない状況に対する注意喚起のようです。

Prismaの解説が参考になりましたのでリンクを貼っておきます。

感想

• これ探してた！やっと見つかった！

• Serverless Application Security Top 10なるものがまた面白そうなので読みたい

• API Security Top 10とMobile Security Top 10もそうですが、やっぱりお互いに被る領域があるな