クラウド・インフラの認証を再考:GitOps のすすめ

Rethinking Cloud Infrastructure Authentication

2021/08/30 SecurityBoulevard — 願わくば p4$$w0r9s を超えて、すべてのクラウド・インフラでセキュアなキーと多要素認証 (MFA) を使ってもらいたいものだ。しかし、それぞれの小さなノードや、ソフトウェア、サーバ、管理コンソールなどにアクセスできる人が、何人いるか把握されているだろうか?スクリプトが実行できるようにするために、どれだけのキーが散らばっているだろうか?信頼できる IP は何個あるだろうか?もし悪意のある人が、これらのうちの1つを手に入れたら、ネットワークがダウンする可能性があるのだろうか?誰かが退職したときに、変更しなければならないパスワードは何個あるのだろうか?

クラウドを変更/再設定するためのアクセス権は、誰にあるのだろうか?もちろん、管理者がアクセス権を持っている。また、CI/CD (Continuous Integration / Continuous Delivery) パイプラインや、物事を変更する様々なDevOpsスクリプトについても考えてみよう。これらは、どのようにして認証され、システムへのアクセスを得ているのだろうか?パスワードだろうか? 信頼できる IP だろうか?それとも MFA だろうか。それらのうちの1つが侵害されたら、どうなるのだろうか?企業における従来からのセキュリティ・アプローチでは、一連のルール (暗号化されたパスワード/TLS/パッチ適用/ファイアウォール) と、それが守られていることを確認するためのスキャンが行われてきた。このアプローチは、企業のデータセンターにロックされた 10台ほどのサーバーの時代には有効だった。 しかし、世界中に分散した数百台の仮想マシンを持つ、クラウドを利用する時代には適合するのだろうか。

分散型アーキテクチャでは、複数の攻撃ベクトルについて考慮する必要がある。その中には、メンテナンスに携わる人がいて、信頼しているソフトウェアやマシンがあり、複雑なシステムにはつきものの設定ミスなどもある。クラウドの環境では、データ/ソフトウェア/コンフィグレーションをコピーする場所が増え、管理すべき認証情報やソフトウェアも増えているため、攻撃対象が広くなり、脅威のモデルも別のものとなる。複数のクラウドをセキュアかつグローバルで運用するには、ソフトウェアの安全性と一貫性を担保する、新しいデプロイメントのアプローチが必要となる。

昨年に、ShiftLeft の Chetan Conikee は、ソフトウェアの開発とデプロイメントの方法を変える、GitOps と呼ばれる新たなアプローチについて、SecurityBoulevard に寄稿している。 GitOps は基本的に、DevOpsに取って代わるものであり、プッシュ・モデルからプル・モデルへの移行を伴う。この新しいモデルは、git リビジョン管理システムで構成され、ターゲット環境で実行されている自律型ソフトウェア・エージェントによって実行される。 このアプローチは、誰と何を信頼するかという問題と、デプロイメントにおける一貫性の問題に対処する。

攻撃べクター

ソフトウェアのデプロイとコンフィグレーションに、従来からの DevOps アプローチで対応すると、いくつかの攻撃ベクターが生じる。

1:資格情報が、ターゲット・インフラに接続するために、ネットワーク全体に保存される。
2:人々は必然的に、コンフィグレーションとソフトウェアが保存されているリポジトリにアクセスできるが、多くの場合、変更を適用するためにターゲット・インフラの一部にもアクセスできる。
3:スクリプトは、特別なコンフィグレーションのために用いられるが、多くの場合において、低レベルのセキュリティ・レビューの対象となり、インフラがアップグレードされると一貫性が失われやすい。 資格情報とアクセスは、このような変更に用いられる、ミニチュア・エージェントへ向けて配布される。
4:ターゲット・インフラは信頼できるものだが、変更を適用するために比較的オープンなアクセスを持つことになる。

これらの攻撃ベクターのカギを握るのは、ヒューマン・エラーだ。ヒューマン・エラーを完全に無くすことはできないが、自動化することで、特定のデプロイメントや変更の際にヒューマン・エラーが発生する可能性を減らし、そのようなミスを修正する時間を短縮できる。

一貫性

バグや脆弱性が悪用されるだけでなく、ミス・コンフィグレーションもセキュリティ侵害の主な原因となる。こうしたミス・コンフィグレーションは、単純な人為的ミスなどの結果として発生する。複雑なシステムでは、ネットワークの問題や、パフォーマンス関連のタイムアウト、単なる不具合などにより、さまざまなエラーが発生する。これらのエラーは、デプロイメントとコンフィグレーションの最中に発生する。時間の経過とともに、システム内における、ノード間の乖離は大きくなる。

DevOps スクリプトのセットとして、コンフィグレーションが適用される場合に、目的の状態へ向けて現状を変化させる方法に焦点を当てると、コンフィグレーションのズレが大きくなっていく。システムを静かに攻撃する方法として、段階的な攻撃手法がある。 DevOps スクリプトは、無害に見える1つのものを変更するが、その変更は悪用されやすい。それを、システムの状態を変更する、正しい方法だと思えるだろうか?

なぜ GitOps は複数の問題に同時に対処できるのか?

ソフトウェアをインストールするだけでセキュリティの理想郷に到達できると言われると、セキュリティの専門家は信じられない気持ちになる。たしかに、GitOps には、オープンソース Flux Project や、Flux を拡張するWeave GitOps などの商用オープンソース製品が含まれている。それらにより、コラボレーション/互換性/ポリシー/可観測性/統合などが推進されるが、GitOps は一連のプラクティスであり、考え方の変化でもある。

この変化のカギとなるのは、開発者や DevOps 担当者がプル・リクエストを提出することで、コンフィギュレーションが宣言的に作成されることだ。このリクエストはレビューされ、適用されていく。ソフトウェア・エージェントがコンフィギュレーションをコンパイルし、ネットワーク上のコンポーネント間における同期の状況を判断する。コンフィグレーションにズレが生じることはなく、認証情報をソフトウェア・エージェント以外と共有する必要もなくなる。したがって、クラウドの構成を展開/変更する際に、エージェント以外を認証する必要がなくなる。

ただし、このプロセスを維持するには、考え方を変えるだけでなく、継続的な規律が必要となる。スクリプトを作成して、何かを変更するのは、とても簡単なことだが、GitOps が適切に実装されるなら、そのような機会は存在しなくなる。つまり、何かを変更するためには、git に保持されている宣言的なコンフィグレーションを実行することになる。GitOps を利用するとき、最初のうちは手間がかかるが、システムの運用を継続しているうちに、時間の節約とエラーの削減が達成され、システム全体が強固になっていく。とはいえ、人間はやはりミスをするし、時には社内の人間が悪意を持つこともある。GitOps では、リビジョン管理に監査可能なログ・システムを組み込むことで、この問題に対処している。誰がやったのかという問題は、単に git blame コマンドを実行するだけだ。また、その理由は、それぞれの git commit メッセージに記載される。

まとめ役

人間の持つ脆弱性や、コンフィギュレーションのズレ、信頼の過剰伝播などは、より良いプラクティスと自動化により軽減できる。GitOps とは、自動化および、ソフトウェア・エージェントによる宣言型の設定、そして固有の監査により、この3つの問題に対処するための、一連のテクノロジーとベスト・プラクティスのことである。GitOps のツールとテクノロジーを使用することで、組織は対象となるシステムにアクセスできる人々やマシンの数を減らすことが可能となり、また、攻撃ベクターを緩和できる。

しかし、GitOps の導入とは、単にインストールではなく、プロセスを変更を伴うものである。CI/CD パイプラインのための一連のスクリプトを使って、オペレータがシステムをディプロイするのではなく、宣言的なコンフィグレーションによる、自動的なデプロイに移行していく。セキュアな GitOps パイプラインを導入することで、デプロイの回数やエラーの数が減り、信頼の輪に関わる人の数も減るというメリットが、セキュリティ担当者にもたらされる。つまり、システムを認証/変更する人々やマシン、そしてスクリプトの数を劇的に減らすことで、人々やマシンによる認証の方法を再考することになるのだ。

原題を直訳すると、「クラウド・インフラの認証を再考」になりますが、内容からして「GitOps のすすめ」を加えたほうが良いだろうと思い、変更しました。クラウドにおけるミス・コンフィグレーションに注目しようという主旨の記事であり、クラウド・プロバイダーたちが提供するものだけでは足りませんという話ですね。これは、クラウド・セキュリティの責任モデルも絡むことであり、必要以上に開発者に負荷をかけない責任モデルが望まれているのかもしれません。なお、原文には 「configuration drift」と言葉がありましたが、「コンフィグレーションのズレ」と訳しています。

Palo Alto Networks のクラウド誤設定検出ツール:背景にある問題とは?

%d bloggers like this: