いよいよ最終回となった Infra Study Meetup #10 に登壇した。
今回はパネルディスカッションということで、今後のインフラ技術について思い思いに喋る回。
パネルディスカッションは(たしか)初めてなので、上手く話せていたのか心配…。あとで YouTube の録画を見て確認します… うまく喋れてなかったらごめんなさい。
さて、登壇にあたって、前回 #9 のパネルディスカッションを見て、おおよそどういう話をするかを予想し、自分なりに今の課題感とか今後の技術についてまとめていました。
今後のインフラ技術…といっても、自分はガッツリとインフラをしているわけではないので、セキュリティエンジニアの目線からどういう課題があるか、今後の発展などについて考えてメモを取っていました。
箇条書きで駄文ですが、せっかくなので、ここに置いておきます。
- 2020年は大きく何かが変化した印象はない
- エッジコンピューティングやゼロトラストなどの 単語 は浸透したように思う
- ゼロトラストの定義…は置いておいて、リモートワークが始まり多くの会社がより便利に安全に社内インフラに接続できる環境を模索していて、その一つとしてゼロトラストという考え方を参考に、IAP や Pomerium のようなツール、サービスの導入はされていると思う
- ただ、それを導入したからゼロトラストだぜ！というわけではないし、ウーン、何なんですかね。ゼロトラスト難しい。
- (ぶっちゃけ原点とか NIST の文書(SP800-207)を読んでいる人どれだけいるんだろう。俺も全部は追いかけていない…)
- エッジコンピューティングやゼロトラストなどの 単語 は浸透したように思う
- だが、数年前からどんどん変わっている印象は持っている
- 1. Policy をコードで書く時代(が来ると思う)
- Hashicorp Vault の Policy みたいなイメージ
- Pod Security Policy(PSP) が deprecated になった
- それによって Lego と OPA(Open Policy Agent) の時代が来ている
- manifest のテストだけでなく、trivy のように脆弱性のフィルタリングにも利用されている
- JSON Validator として利用できるので、アプリケーション間での通信の検証にも利用できる
- 一方で PSP の代替案の道は分断されてきている印象
- 例えば AKS は Azure Policy を使うようになっている
- 2. 守る仕組みの変化への対応
- コンテナではコマンドの実行や FIM などの監査方法が変わってくる
- FIM … そもそも ReadOnly な fs になる。しかし PVC などの監査をどうする?
- auditd … コンテナの namespace や pod 名など、あとから追跡するために必要な情報が(現段階では)足りない
- 一応話としては出ていてカーネルへのパッチもあった気がするが…
- これらをトレースできる仕組みが必要になってきており、カーネルモジュール、eBPF が利用されている(falco など)
- auditd と falco を比較してパフォーマンス的にもいいみたいなレポートもある(ただし、出どころが sysdig だったと思うのでポジショントークもありそう)
- また、Pod はライフサイクルも短いため、取得する情報はより詳細に得る必要もある(し、取りこぼしがないようにしないといけない)
- コンテナではコマンドの実行や FIM などの監査方法が変わってくる
- 3. デフォルトで安全な世界になる(していく必要がある)
- Web の世界では SameSite Cookie を始め、仕組み自体を安全にすることでセキュアな Web を実現してきている
- インフラも OS, ミドルウェアのレイヤーでセキュアな設計になるのが望ましい
- 実施に Kubernetes 向けに設計されたディストリビューションや gVisor や Kata Container のようなものが出てきている
- 少しでも安全になるように Rust で書き換えるとか
- (サービスを守る)セキュリティエンジニアとしては、そのような環境を用意するためにポリシーを用意したり、それを集中管理できるような仕組みづくりが求められると思う
- しかし、仕組みを用意するだけではダメで、守るアプリケーションとポリシーの数は比例するため、セキュリティエンジニアだけでは破綻する
- アプリケーションのコンテキストを理解した上で、ポリシーを緩めるのか、それともアプリケーション側を直すのかを決める必要がある
- そのためには dev/ops チームとの協業が必要になる
- チームとして全員でそれに取り掛かるのか、あるいはセキュリティ担当者を決めるのか、そこは組織にあった形になるが、そのような体制作りも同時に進めなければならない
- しかし、仕組みを用意するだけではダメで、守るアプリケーションとポリシーの数は比例するため、セキュリティエンジニアだけでは破綻する
- (脆弱性をトリアージする身として) Kubernetes を始めとした基盤技術は複雑かつ登場人物も多いので、正確な影響範囲等を調べるためにも、使われている技術はひたすら動かして理解を深める必要がある
- 1. Policy をコードで書く時代(が来ると思う)
以上、自分の頭の中をそのままアウトプットした感じですが、読みにくいですね… いつかちゃんと文章を書こう…(本当に?)。 セッションの捕捉にもなると嬉しいです…。
最後に、Infra Study を運営してくださった @matsumotory さん、Forkwell さん、天神放送局さん、そしてスポンサー企業の皆さんもありがとうございました。
とてもいいコミュニティでしたし、これからのオンラインイベントのあり方みたいなイメージを広げてくださったと思います。
またいつかやりたいですね…!