最小権限はホームサーバーアプリ全体の被害をどのように抑えるのか？

最小権限は、各ホームサーバーアプリが、その役割に必要なファイル、デバイス、ネットワーク、シークレット、操作にだけアクセスできるようにすることで、被害を限定します。

セルフホスト型サーバーでは、メディアツール、写真管理、ダウンローダー、ダッシュボード、データベース、スマートホームサービス、AIエージェント、バックアップ処理などを1台のマシンで実行することがよくあります。コンテナによる分離があっても、これらのアプリが同等に安全になるわけでも、無害になるわけでもありません。Dockerソケット、広範なバインドマウント、ホストネットワーク、root権限、管理者トークンを持つサービスは、読み取り専用のライブラリブラウザーよりはるかに広範囲へ影響を及ぼせます。以下では、権限を複数の独立した側面として捉え、アプリが侵害された後に、それぞれが被害範囲をどのように変えるかを説明します。

実効権限の範囲が被害範囲を決める

脆弱性がより大きなインシデントへ発展するのは、侵害されたプロセスが、自身の限定された処理範囲を超えて価値のあるリソースへアクセスできる場合だけです。重要なのは、コード実行が発生したかどうかだけではなく、そのプロセスが何を読み取り、変更し、呼び出し、なりすます権限を持っているかです。

セキュリティチームは、1つの脆弱性が悪用された後に露出するシステム、データ、ユーザーを表すために、被害範囲という言葉を使います。ホームサーバーでは、インシデントが1つのアプリデータベースで収束するか、家族のファイル、バックアップ、カメラ、管理機能にまで広がるかを権限が左右します。

したがって、最小権限はアーキテクチャによる封じ込めの手段です。あらゆる侵害を防ぐわけではありませんが、コード実行に成功した後に実行可能な操作を減らします。

ファイルシステムの範囲が読み取り・破壊可能なデータを決める

家庭内のデータをマウントしていないコンテナであれば、通常のファイルシステムアクセスによって写真アーカイブを暗号化することはできません。同じイメージでも、ストレージプール全体への書き込み可能なマウントがあれば、コンテナを削除しても残るデータに損害を与えられます。

ZimaSpaceによるバインドマウントの範囲に関する分析は、正確なホストパス、読み取り・書き込みモード、所有権、ラベルがセキュリティ境界の一部になる理由を示しています。狭い読み取り専用のメディアパスと、サーバールート全体への書き込み可能なマウントでは、結果が根本的に異なります。

アップロード、データベース、キャッシュ、生成ファイルには、それぞれ分離した書き込み可能な場所を割り当て、広範な親ディレクトリを公開しないようにします。すべてのストレージが1つの便利なパスの下にあるからといって、バックアップフォルダーや無関係な家族のデータまでアプリに与えるべきではありません。

読み取り専用アクセスでも情報漏えいは起こり得ます。アプリが参照する必要のない機密文書やシークレットは、マウントしないでください。

非rootユーザーとケイパビリティがホストへの権限を減らす

専用ユーザーとして実行すれば、通常のUID、GID、ファイルシステムのルールによってアクセスを制限できます。不要なLinuxケイパビリティを削除すれば、通常のアプリケーションには必要ない、カーネルレベルの特定の権限もさらに取り除けます。

Snykの説明によると、Linuxケイパビリティは、rootに近い権限をより小さな権限へ分割します。1つのポートをバインドする必要があるサービスに、広範なデバイス、ネットワーク、マウント、プロセス制御の権限は必要ありません。

非rootでの実行は、マウントやシークレットの管理に代わるものではありません。非rootプロセスでも、所有権やグループ権限によって書き込みが許可されているマウント済みファイルは変更できます。

特権モード、ホストデバイス、Dockerソケットは、通常の複数の封じ込め層を一度に迂回できるため、明示的な管理者向け例外として扱うべきです。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

ネットワーク到達範囲がアプリの横方向への移動を決める

アプリケーションに必要なのは通常、1つのデータベース、1つのプロキシ、または選択したインターネット接続先であり、すべてのコンテナ、NASサービス、カメラ、ルーター、家庭内クライアントへの無制限のアクセスではありません。

コンテナセキュリティのガイダンスでは、侵害後の被害範囲を抑えるためにネットワーク分離を利用します。分離されたブリッジ、制限付きの送信トラフィック、ファイアウォールルール、サービス専用ネットワークによって、内部の探索や横方向の移動を困難にできます。

リバースプロキシを使えば、アプリケーションをホストネットワークへ直接配置せずに、意図したWebインターフェースだけを公開できます。データベースへの接続は、利用するサービスからのみに限定してください。

双方向をテストしましょう。受信アクセスを遮断しても、送信経路が開いたままであれば、侵害されたアプリがLANをスキャンしたり、ファイルをアップロードしたり、内部APIを呼び出したりすることは防げません。

シークレットとAPIスコープが下流で実行できる操作を決める

サービスアカウントによって、侵害がローカルプロセスの範囲を超えて広がる可能性があります。トークンによっては、クラウドバックアップの削除、DNSの変更、スマートホームデバイスの操作、メッセージの送信、別のサーバーの管理まで許可されることがあります。

最小限のアクセスという原則は、コンテナランタイムだけでなく、各認証情報にも適用されます。IDを分離し、リソーススコープを狭め、読み取り専用権限と短い有効期間を使用し、破壊的な操作には人による承認を求めてください。

アプリ専用の認証情報を作成するより簡単だからという理由で、管理者トークンを使い回してはいけません。低権限のコンテナでも、高権限のAPIキーを持っていれば、実効的な被害範囲は大きくなります。

プロセスがすでに侵害されていると想定してアプリをテストする

composeファイルだけでなく、実行中の設定を確認してください。実効ユーザー、グループ、ケイパビリティ、マウントパス、デバイスアクセス、環境変数、シークレットファイル、ネットワーク、開いているポート、到達可能なAPIを確認します。

ランタイムのガイダンスがランタイムによる封じ込めを推奨するのは、イメージスキャンだけでは、アプリの起動時に付与されるすべての権限を明らかにできないためです。アプリの実際の認証情報を使って、無関係なファイルの読み取り、隣接サービスへの接続、書き込み操作を試みてください。

例外が存在する理由をすべて記録し、現在のワークフローで使われていないアクセスを削除します。機能が変わった後も古いマウント、ネットワーク、グループ、トークンが残っていると、権限が徐々に拡大します。

目標は、予測可能な失敗境界です。1つの写真アプリが侵害されても、そのカタログと割り当てられたライブラリは露出する可能性がありますが、サーバー管理機能、家庭内のバックアップ、他のすべてのアプリまで自動的に解除されるべきではありません。