注：本記事は(2022年3月9日)に公開された(Introducing SansShell: A Non-Interactive Local Host Agent)を翻訳して公開したものです。
この度Snowflakeでは、非インタラクティブ型ローカルホスト管理エージェント「SansShell」をオープンソースとしてリリースすることになりました。その目的は、あらゆるタイプのサーバーの認証、承認、および管理監査の強化です。ソースコードはGitHubにて入手できます。
基本的にSansShellは、複雑なサーバー管理アクションをコードで定義し、リモートクライアントへと選択的に適用する手段として設計されています。各アクションは、呼出元、アクションのタイプ、および要求の内容に応じてアクセスを制限できる承認ポリシーに従って管理されます。モジュラー式または拡張可能な形式での構築が可能であることに加え、新しいアクションタイプの定義、不要となったアクションの削除、および認証エンジンやポリシーエンジンの交換も簡単に行うことができます。
SansShellは軽量gRPCサーバーとして実装され、一般的な管理アクション（ファイルの読み込み/修正、コマンドの実行、パッケージのインストールなど）をリファレンス実装しているほか、mTLS認証に対応しており、承認ポリシーはRegoで作成されています。
SansShellは非インタラクティブなソリューションであるため、メンテナンスアクションが安全であるかを事前に評価しコードレビューをしたうえでポリシーに直接エンコードできます。さらに、あまり安全でないアクションも、事後のきめ細かなアクション監査を可能にするという非常に強力な保証に基づいて安心して許可することができます。またSansShellはこうしたアクションに対してローカルなマルチパーティ承認を事前に義務付けることもできるよう設計されています（この義務付け機能は近日提供開始予定です）。このように、SansShellは超低依存型緊急アクセスに適している一方、必要なアクションに関する優れた監査ログを保持します。
SansShellプロキシ
SansShellは、環境内の複数の、おそらくすべてのマシンに広範囲に展開できますが、予期せぬ一斉シャットダウンのリスクを避けるため認証および承認ポリシーの変更はゆっくりと慎重に行う必要があります。トラブルシューティングやインシデント対応を活発に行っている最中にSansShellのローカルポリシーを急激に拡大しようとするのは重大なリスクを伴います。また一部のアクション（特定のファイルのチェックサム計算など）はしばしば多くのマシンをまたいで実行されるため、ユーザーのワークステーションから直列的に実行すると時間がかかり、エラーも発生しやすくなります。
こうした課題に対応するため、SansShellは、ユーザーとSansShell実行マシン間に展開できるスマートプロキシサーバーを備えています。このプロキシは、詳細なポリシー適用やログ記録のリクエストのための単一の管理ポイントを提供するほか、単一のリクエストを複数のSansShellサーバーに同時に展開することも可能です。ユーザーは、ダイレクトなネットワークアクセス権限を取得する必要なしにSansShellサーバーに承認済みリクエストを送信でき、これにより各エンドポイントのネットワークポリシーを制約性の高いものにすることができます。プロキシ層ポリシーの更新は、SansShellサーバーを実行しているすべてのエンドポイントを変更するリスクを伴わずにスピーディーに収斂されます。
SansShellを構築すべき理由
Snowflakeは可能な限り強力なカスタマーデータの保護に取り組んでおり、既存のSnowflakeクラウドVM管理メソッドは、アクセス制限や監査層を追加したOpenSSHを基盤とする業界トップのベストプラクティスツールを採用しています。Snowflakeのインフラストラクチャの大部分はイミュータブルもしくはその場で更新されますが、一方で当社のオートメーションでは対応できない不測の事態に対し、全てのイミュータブルなインフラをリサイクルしようとするよりも迅速な対応ができるよう、緊急の「突破口」を用意しておく必要があります。そうした稀なケースでさえもインタラクティブなセッションから非インタラクティブなアクションへ移行させることにより、Snowflakeの監査機能は想定し得る最も高度なセキュリティ脅威に対しても攻撃クラス全体の排除により確実に検出し対処する能力を実現できるでしょう。それと同時に当社のオートメーションでは対処できない万が一のシナリオにもすばやく対応する体制を維持することができます。
SnowflakeのVMメンテナンス作業に関わるこうした要件を達成するには、非インタラクティブAPIに移行して稼働ホストを修正する必要があると私たちは考えました。このことは、Snowflakeのイミュータブルなインフラストラクチャモデルに現状まだ組み込まれていない定期メンテナンスの実装と、アクティブインシデントへの対応に伴うやむ負えない緊急メンテナンスの両方に当てはまります。私たちはいくつかのオプションを検討しましたが、ニーズに十分適したソリューションは他には見つかりませんでした。
なぜオープンソースなSansShellでなければならないなのか
Snowflakeの「Choosing Open Wisely」（オープンソースツールを賢く選択する）の原則を鑑みると、今回のユースケースは正に、業界最高レベルのセキュリティ達成、将来のSnowflakeにとって当たり前になるであろう新たなホスト管理基準メリットの享受、そして願わくはオープンソースモデルが提供する強力なセキュリティ監視機能のメリット享受につながるケースでした。FoundationDBと同様、「オープンを選ぶ」ことは業界および当社にとって利益をもたらすものと確信しています。
私たちは、SansShellがいかにSnowflakeのインフラストラクチャ管理を進化させてくれるかについて大きな期待を抱く一方、シンプルなカスタマーAPIへの注力も続けていきます。私たちは、SansShellやFoundationDBといったインフラストラクチャ層がSnowflakeの内部実装であり続けることが重要だと確信しています。これにより、Snowflakeのデータセキュリティとガバナンスは、ユーザーの目に見える形で時代の変化に伴い進化し続けることができます。シンプルかつエレガントで安定的なパブリックAPI構築を目指すSnowflakeの取り組みにより、ユーザーはインフラストラクチャの管理に煩わされずデータからの価値抽出に集中できるでしょう。