Zero Touch Production という運用手法

ZTPとは何か #

• システムの開発・運用者による本番環境への直接的アクセスを制限し、より安全で安定的な本番環境を実現しようという概念
• GoogleのSREチームが提唱して取り組んでいる

ZTPが興った背景 #

DevOpsなどの流行により本番環境にアクセスする機会が減り、本番環境へのアクセス機会がかなり減ってきている。

• Infrastructure as Code と CI/CD による環境構築とデプロイの自動化
• DataDog/Mackerel/Prometheus などの監視ツールによるログとメトリクスの中央管理
  • 障害時にサーバーに乗り込んでコマンドを叩く必要がなくなってきている

なぜ本番環境への直接アクセスは良くないか #

• 個人の端末に認証情報を持つ危険性
  • 漏洩してしまうと…
  • 特に最近ではその端末が各家庭のネットワーク内で動いている
  • 最小権限の原則
    • 権限の強さ付与される時間は基本的に最小化されるべき
• Googleの内部調査では障害全体の13%が本番環境に直接アクセスして操作を行ったことに起因しているという結果が出た
  • 人間は間違える

ZTPの実現(Googleの事例) #

Proxyを経由した本番環境アクセスの仕組みを構築して実現しているらしい

※画像は参考資料として最後にリンクを貼っているbuilding-secure-reliable-systemsから。

以下のようなコマンドを通してオペレーションを実行するイメージらしい。

$ tool-proxy-cli –proxy_address admin-proxy borg kill …

アプリケーションの変更IF #

• SSHで接続してどんなコマンドでも実行できるような変更IFを提供していると意図しない迂回経路などが発生してloggingやauditingに影響が出てしまう。
• SSHのforce commandを利用したり、変更IFとなるサイドカーを用意したりして小さく保つことが重要
• IAMなどを用いた権限の制御も重要

承認サービス #

• 幅広い観点でチェック可能であることが望ましい
• 素早い承認が生産性にも響いてくるのでProxy側で行う機械的なチェックなどのサポートがあると良い
• 忖度しない風土づくりもとても重要

Breakglass #

• 緊急時に直接システムにアクセスすることを許容するための仕組み
  • 一時的なIAM払い出しなど
• 何事も想定外は発生するのでこの仕組みを用意しておくといざというときに迅速なサービス復旧につなぐことができる
• ただし、Breakglassの利用には格別の注意が払われる必要がある

ZTPのトレードオフ #

• ZTPを実現するための仕組みを構築するコストとシステム的な複雑さの増加
• 承認者の応答が悪いと生産性が低下してしまう
  • ときには平均修復時間(MTTR)に影響を与え、ユーザーへの影響が拡大してしまう可能性も

OSSで提供されているもの #

• Googleが使っているという仕組みは特にOSSなどで提供されていない模様
• Lyft社のClutch
  • ZTPと似たモチベーションで作られている？
  • CLIだけでなくGUIも提供してくれている
  • https://github.com/lyft/clutch
• Hashicorp社のBoundary
  • ZTPというよりはZero Trust Networkのツールに近そう
  • オペレーターに本番環境クレデンシャルを持たせないなど、部分的な実現はできる
  • https://github.com/hashicorp/boundary

参考 #

https://sre.google/books/building-secure-reliable-systems/

https://deeeet.com/writing/2020/10/15/zero-touch-production/%