Aiven Security Agent for PostgreSQL®の翻訳です。

2022年8月11日

PostgreSQL® 用 Aiven セキュリティエージェント

PostgreSQLの拡張機能はユーザーに素晴らしい機能を提供しますが、安全に提供することは困難です。Aivenはこの問題をオープンソースで解決します！

問題...

AivenはPostgreSQL®をDatabase as a Service (DBaaS)として提供しています。サービス提供の一環として、顧客には特権ユーザー(avnadmin)が与えられます。しかし、superuser 権限はこのユーザーには与えられていません。スーパーユーザー権限では、すべての権限チェックをバイパスすることができ、データベースを再設定することができます。スーパーユーザー特権はまた、基礎となるホスト上で、ファイルの読み取りやプログラムの実行といったインタラクションを可能にする機能へのアクセスも提供します。

データベースは便利ですが、拡張機能によってさらに便利にすることができます。PostgreSQLは多くの便利な拡張機能をサポートしており、私たちは顧客がそれらの拡張機能を使用できるようにしたいと考えています。残念ながら、PostgreSQLの設計上、ほとんどの拡張はインストールに昇格（スーパーユーザ）権限を必要とします。これはセキュリティ上の難問を生み出します: スーパーユーザ権限なしで顧客が拡張機能をインストールできるようにするにはどうすればよいでしょうか?

意図したとおりに動いていますか?

多くの（あるいはほとんどの）セキュリティー問題で苦労するのは、それが文脈上のセキュリティー問題でしかないということです。実際には、ほとんどの文脈で必要とされる機能なのだ。セキュリティ業界はこのことに苦慮しており、しばしば、アーキテクチャの設計作業や開発者の能力がいかに不十分であるかが本当の問題であると熱弁をふるう。前述の通り、AivenのようなDatabase Platform-as-a-Serviceの場合、これはさらに悪化する。私たちは、どのような状況下でも顧客がデータの管理を任せられるという安心と信頼を売りにしています。

アプリケーション設計者、セキュリティ（およびコンプライアンス）業界、そして顧客の信頼という3つの競合の間で、どのようにこのバランスを提供すればよいのでしょうか？私たちは、顧客が不必要なリスクを負うことなく、サービスの恩恵を十分に受けられるようにする必要があります。また、**私たちはこのような共通の利害を持つため、顧客と負担を分かち合うようにする必要があります。

より多くの脆弱性 = より多くのパッチ

新たなセキュリティ脆弱性が発見され、ほぼ絶え間なくパッチが適用される中、私たちはこのハムスターのような苦しみを経験し続けています。Aivenのように顧客データと密接に関わる仕事をしていると、メンテナンスのたびに、顧客の最も重要な資産、さらには顧客の機能に対する潜在的なリスクが発生します。

私たちはポストセールス・ソリューション・アーキテクト・グループと協力し、お客様がAivenのサービスを可能な限り回復力、可用性、耐障害性に優れたものになるよう設計するよう努めています。2021年12月を振り返ってみると、私たちは0decemberを経験し、Log4jプロジェクトが新しいパッチを次々とリリースしたため、一連のメンテナンスイベントが重なりました。

##症候性パッチ

脆弱性 → パッチ → 脆弱性-わずかな変化 → 脆弱性-わずかに異なるトリガー条件のパッチ → 脆弱性-突然変異-ナンバー3 → 脆弱性-いくつかの追加的な突然変異をキャッチするパッチ このパターンは、すべての関係者にとって非常にコストがかかる。それにもかかわらず、オープンソース開発チームの能力や能力が、脆弱性のクラス全体に対する耐久性のある修正を提供するのに十分でないことがあまりにも頻繁にあります。

私の意見では、これはオープンソース・ソフトウェアの使用を通じて利益を得ている大企業の最大の失敗の1つである。彼らは、問題を真に修復するために必要な適切な（しばしば高価な）アーキテクチャの変更にお金を払う気がないようだ。この対症療法的なパッチ・サイクルこそ、オープンソースの世界が最善の努力として受け入れなければならないものなのだ。開発者は、自分たちのプロジェクトのユーザーと同じように、いやそれ以上に、このことにフラストレーションを感じている！

セキュリティ業界の人たちには、指をさして「十分ではない」と言う前に、開発者の立場になって考えてみることを勧めたい。大義のためにベストを尽くし、自分がすでに倒れているときに蹴りを入れられることに気づくのは、精神的に完全に疲れるに違いない。

違うアプローチをとる

私が毎日仕事に行くのが楽しくて目が覚める理由のひとつは、Aivenの投資家、取締役会、経営陣が、症状に対するつぎはぎだらけのこの終わりのないサイクルに対して、異なるアプローチを取る権限を私に与えてくれたことです。

半年ほど前から、PostgreSQLの拡張機能の問題に関連したバグ報奨金や社内の製品セキュリティに関する発見が増え始めました。私たちは、これらの拡張機能に懸命に取り組んでいる開発者に代わって、この周期的な痛みを経験していました。私たちは悪い知らせの運び屋にならざるを得ず、時には同じパッケージについて、疲弊しきった同じ開発者と何度も議論しなければなりませんでした。ありがたいことに、Aivenには素晴らしいチームがあり、私たちのセキュリティ・アーキテクトEtienne Stalmansは、私たちが目にしてきた拡張機能関連の問題の全クラスに対して実行可能な緩和策を発見しました。

完全な解決策ではありません。完全な解決策は、何十年も前から存在するPostgreSQLの基本を再構築することでしょう。しかし、何もしないよりはずっとましです！

PostgreSQLの拡張とAivenの実装方法

このソリューションを理解するために、Aivenがどのように顧客のために拡張機能管理を実装しているかを見てみましょう。少し技術的な話になるので、Etienneの言葉をそのまま引用します：

Aivenでは、お客様が定義済みの拡張機能リストを有効にすることができます。拡張機能のインストールに必要なスーパーユーザーアクセスを回避するために、pgextwlist拡張機能を使用して、より低い権限のユーザーから拡張機能を作成できるようにしています。pgextwlistは、まずデフォルトのスーパーユーザーであるpostgresに権限を昇格し、拡張機能のインストールスクリプトを実行することで機能します。これにより、Aivenは特権昇格攻撃のリスクにさらされることになります。これはPostgreSQLに明確に文書化されています：https://www.postgresql.org/docs/current/sql-createextension.html.

残念ながら、PostgreSQLドキュメントの警告にもかかわらず、非常によくあることなのですが、拡張機能のインストールスクリプトが安全でない方法で書かれた場合、ユーザがスーパーユーザ権限を得ることが可能になってしまいます。

*拡張機能作成後に権限の昇格を許してしまう、拡張機能におけるもう1つのよくある設定ミスは、SECURITY DEFINER関数内でスキーマ修飾関数を使用せずにSECURITY DEFINERを使用することです。拡張機能はスーパーユーザによって作成されるため、SECURITY DEFINER関数はスーパーユーザ権限で実行されます。これは、攻撃者が制御する関数を高い権限で実行するために悪用される可能性があります。

顧客を有効にすることと、悪いこと（Bad Things™）を発生させることとの間のこのバランスは、顧客にとって良い結果を確実にするための絶え間ない戦いです。

私のエクステンションは敵対的ですか？

このようなPostgreSQLの拡張機能に関するインバウンドの問題が増加しているのを見るにつけ、ほとんど答えのない疑問が投げかけられました。pghostileが登場しました。これはセキュリティ技術チームが開発した内部ツールで、今日オープンソースとして公開できることに興奮しています！

プロジェクトのreadme.mdから：

*PghostileはPostgreSQLをスーパーユーザにとっては敵対的な環境にし、攻撃者にとっては格好の遊び場にすることができます。Pghostileは "system "関数（'pg_catalog'スキーマの関数）をオーバーライドする自動化ツールであり、これらの関数がスーパーユーザによって呼び出された場合、攻撃者は特権を昇格させることができます。

*PostgreSQL拡張のセキュリティをテストするためにも使用できます。pghostileを実行して "exploit関数 "を作成し、拡張モジュールの単体テストを実行して、スーパーユーザの権限が得られるかどうかを確認することができます。

結局のところ、PostgreSQLにはこの種の問題がたくさんあり、pghostileは現時点で約900の問題をチェックしています（プルリクエスト歓迎！）。私たちはこのリリースで素晴らしい仲間に加わりました。TimescaleのSven Klemmによる素晴らしいツールpgspotを使えば、PostgreSQL拡張によくある設定ミスを簡単に特定することができます。

拡張機能の権限昇格の保護

このような脆弱な拡張機能をさらに探すのに役立つツールをオープンソースにすることは、「典型的なセキュリティの動き」のように聞こえます。私たちの価値観である「オーナーシップ」、「オープンネス」、「勇気」は、私たちをそれ以上の存在へと押し上げています。私たちは、このような拡張機能ベースの権限昇格攻撃全体から顧客を守る必要がありました。しかし、私たちが顧客のために構築したソリューションをオープンソース化すれば、何百万ものPostgreSQLデータベースを守る手助けをすることもできるのです。

Aiven Security Agent for PostgreSQL(aiven-gatekeeper)は、どの特権関数が公開されるかを制御し、一般的な特権昇格攻撃で悪用されるのを防ぐことができます。

エージェントはPostgreSQLサーバの起動時に共有ライブラリとしてロードされ、PostgreSQLエンジンがユーティリティ関数を実行する前に、UtilityProcessフックを使用してユーティリティ関数の実行を傍受します。現在の実行状態を検査し、特権動作を許可すべきかどうかを判断することで、セキュリティ判断を行うことができます。

エージェントは、関数を許可または不許可にする前に、以下の3つの基準を使用してリスク評価を行います：

• creating_extension
  • CREATE EXTENSION関数の実行中に関数が実行される。
• is_elevated
  • 現在のユーザはスーパーユーザであるが、セッションユーザがスーパーユーザ権限を持っていない場合、実行コンテキストは "elevated "とみなされる。これはCREATE EXTENSIONまたはSECURITY DEFINER関数の実行中に発生する。
• is_security_restricted` です。
  • PostgreSQLは現在の実行コンテキストをSECURITY RESTRICTEDに設定することができます。エージェントはこれらの既存の制限を補完します。

セキュリティエージェントは3つの主要なユーティリティ関数を調べます：

• ロールの変更/作成/付与
  • スーパーユーザ権限でロールを変更、作成、付与する場合。
  • スーパーユーザ権限でロールを変更、作成、付与する場合：pg_read_server_files、pg_write_server_files、pg_execute_server_program`。
• 上記の権限を持つ既存のロールにロールを追加しないようにする。
• プログラムへのコピー/プログラムからのコピー
  • これは通常スーパーユーザか pg_execute_server_program 権限を持つロールのために予約されています。これはコンテキストに関係なく常にブロックされます。Aivenプラットフォームでは、PostgreSQL内からホストコマンドを実行する理由はありません。
• ファイルへのコピー/ファイルからのコピー
  • この機能は通常スーパーユーザか pg_read_server_files または pg_write_server_files 権限を持つロールのために予約されています。これは昇格したコンテキストではブロックされます。

セキュリティエージェントは、特定の組み込み関数とその派生関数へのアクセスもブロックします：

• pg_read_file
• pg_read_binary_file
• pg_reload_conf
• lo_import
• lo_export

これらの関数はすべて基礎となるファイルシステムに対して読み込みまたは書き込みを行うことができ、コマンド実行を行うために連結することができます。

最後に、内部テーブル pg_proc と pg_authid に書き込めるものと書き込めないものに制限がある。

エージェントは静かに動作し、PostgreSQLの正当な機能に干渉しないように設計されています。性能に影響を与えないよう、あらゆる努力が払われています。ほとんどの優れたセキュリティガードレールのように、実際に必要になるまでその存在に気付くべきではありません。

信頼は獲得され...検証される

重要なクラスのセキュリティ脆弱性を解決すると主張するソフトウェアを書くことは一つのことだ。そのソフトウェアの作者が良い仕事をし、あなたのデータの永続的な保存を担う本番システムにインストールすることを信頼することは、まったく別のことである。これは、私たち自身だけでなく、顧客と共有するこの重荷を経験することで、私たちが直感的に理解していることです。

私たちの仕事が私たちが考えているほど良いものであることを検証するために、私たちは友人や元同僚など、思いつく限りの人に声をかけ、私たちの仕事をレビューしてもらい、ソリューションのアーキテクチャと実装について2番目（3番目、4番目、n番目！）の意見を提供してもらいました。この数カ月間、私たちが開発を進める中で、これらのレビュアーの何人かが実際にAiven Security Agent for PostgreSQLを本番環境に実装し、数百万ものデータベースの保護に役立っていることを私たちは知っています。

このように専門家から信頼を得ているにもかかわらず、私たちができることはまだそれだけではありません。私たちは、アプリケーション評価と侵入テストのパートナーの1つであるLeviathan Security Groupに連絡を取り、Aiven Security Agent for PostgreSQLを評価し、その結果を公表するための作業指示書を提供してくれるよう依頼しました。

個人的には、そのSoWにサインオフし、作業を完了できたことを非常に嬉しく思っています。オープンソースプロジェクトの第三者による検証はまだ珍しいことです。彼らの報告書全文と、監査、リスク、またはコンプライアンス担当者と共有するのに適したレターを読むことができます。私たちはまた、これらの文書をソース・リポジトリの一部として含んでおり、プロジェクトに重要なコード変更が加えられるたびに更新する予定です。

結論として

Aivenのアプローチは、可能な限り元のサービス機能を維持することです。AivenはPostgreSQLのカスタムフォークを実行することを目的とはしておらず、自前のPostgreSQLインスタンスから移行する顧客は何を期待すべきかを知るべきです。PostgreSQLのフック機構を使用することで、既存のPostgreSQLの機能を拡張し、安全で予測可能な方法でセキュリティを追加することができます。これはまた、PostgreSQLのバージョン間でソリューションを移植可能にします。何よりも、このソリューションのオープンソース化が非常に簡単で、誰でも再デプロイやシステムの根本的な変更なしに、既存のPostgreSQLインスタンスに組み込むことができます。

エージェントはPostgreSQL拡張機構の設計上の制限の中で動作するため、"100%"の解決策にはなり得ません。行レベルセキュリティ(RLS)をバイパスするような特権的な操作の可能性をすべて防ぐことはできませんが、悪用された後の操作の可能性を排除することはできます。これはまた、拡張機能のインストールと特権コンテキストに関する強固な監視と警告を構築し、悪意のある操作を検出することを可能にします。

Aiven for PostgreSQLをご利用のお客様は、2022-07-08以降に起動したすべての新規インスタンス、またはそれ以降に利用可能なメンテナンスアップデート(Aivenの全PostgreSQLインスタンスの99.91%)を完了した場合、Aiven Security Agent for PostgreSQLによる保護を受けています。まだこのメンテナンスを実施していない場合は、できるだけ早く実施してください。

私より遥かに賢明な人々の言葉を借りれば、"何か "は "何もない "よりも "限りなく大きい "のです。私は、上からの完全なサポートを受けながら、Aivenのセキュリティ・エンジニア、開発者、アーキテクトからなるこの素晴らしいチームを率いることができて、とても光栄に思っています。

私たちはコミュニティにとって本当に有益なものを提供できたと信じていますし、コードに対する私個人の貢献はまったく何もありませんが、チームは素晴らしい仕事をしてくれました。投資家、取締役会メンバー、役員チームメンバー、オープンソースプログラムオフィススタッフ、私たちの仕事をテストしてくれた友人や元同僚、無名のサードパーティ組織（あなたは誰だか知っていますね！）、Leviathan Security Groupチーム、PostgreSQL用Aiven Security AgentであるPGhostileの開発チーム、そして特に、私たちに再び信頼を得る機会を与えてくれたお客様に感謝します。

--

Aivenと私たちのサービスに関する最新ニュースや、オープンソースに関するちょっとした情報を入手するには、月刊ニュースレターを購読してください！Aivenに関する日々のニュースは、LinkedInとTwitterのフィードでご覧いただけます。

サービスアップデートの情報を知りたい方は、変更履歴をご覧ください。