通信中に権限を継続的に再評価する方式と、方針の実施を検証する仕組みの三場面での測定
研究計画。通信の間ずっと権限を決め直す方式と、決めた方針が本当にその通りになっているかを検証する仕組みを、三つの場面で測る
接続を始めるときに一度だけ認証して、あとは通してしまう作りをやめられるかを調べる。社内のアクセス制御、サービス同士の横の通信、複数のクラウドを跨いだ方針という三つの場面を扱う。前の二つは、通信の間ずっと危険度を更新し続けて権限を段階的に変える方式を測る。三つ目は角度が違い、そもそも書いた方針が本当にその通りに効いているのかを、設定から計算して確かめる。続けて確かめることと、確かめた内容が正しいことは別の問題である。本ページは計画であり、実験はまだ行っていない。以下に実測値は無い。
| 方法 | 続けて確かめる制御では、隔離した環境に匿名化した身元を割り当てたサービス群を置き、正常なアクセス、状態の変化、権限の変更、普段の分布からの逸脱を作る。危険度は説明できる複数の手がかりの重み付けから始め、閾値と見直しの周期を変えて比べる。サービス間の通信では、小さなマイクロサービスの環境を作り、表から API、サービス、データベースへと至る正常な呼び出しの連なりを反復したうえで、普段存在しない要求、異常な反復、身元と権限の食い違いを作る。クラウドを跨いだ方針の検証では、各クラウドの設定を共通の図とその制約に変換し、研究者が宣言した意図と、設定から計算した実際の到達可能性を突き合わせる。実際のアカウントの設定は公開せず、合成した構成を多数生成し、正しい構成へ一箇所ずつ変更を加えて、違反を見つけられるかを測る。 |
|---|---|
| 結果 | 実験前である。本ページに実測値は無い。「予想」として書いたものは検証前の仮説であって、測定の結果ではない。 |
| 知見 | 三つに共通する問いは、確かめる回数ではなく、確かめ続けたときに何を失うかにある。見直しを増やせば異常に早く気づけるが、手がかりが不安定だと権限が上下に揺れ、正常な通信まで巻き込む。そして見直しをいくら増やしても、見直している内容そのものが意図とずれていれば意味がない。三つ目の研究は、その前提を測りにいくものである。 |
| 限界 | 小さなテスト環境と実環境の差。データの量と偏り。ソフトウェアと版に結果が左右されること。正常そのものが時間とともに変わること。記録の欠落と、機器ごとの時計のずれ。合成した構成が、実際のクラウドの設定の複雑さを代表しているとは限らないこと。変換できない設定の書き方が残ること。研究チームが2名であるため、初めに扱う対象を絞る必要があること。 |
状態：実験前。この記事は研究の目的と方法を先に公開するための記録である。数値はまだ一つも出ていない。以下に「予想」と書いたものはすべて検証前の仮説であり、実測値として扱わない。
原則は決まっていて、作り方が決まっていない
ネットワークの上の場所を信頼の根拠にしない、という考え方は NIST SP 800-207 が示し、クラウド上のアプリケーション間へは SP 800-207A が広げている。原則としては受け入れられている。しかし実際に作るときに残る問いは別にある。どれくらいの頻度で、どの手がかりを見て確かめ直せば、正常な通信を止めずに異常へ早く反応できるのか。
この問いには、二つの層がある。一つは、確かめ続ける仕組みをどう作るか。もう一つは、確かめている内容そのものが、意図した方針と合っているか。前者ばかり議論されるが、後者が崩れていれば前者は無意味である。この計画では両方を扱う。
続けて確かめるアクセス制御
接続を始めるときの認証と認可だけでなく、通信の間の身元、機器やサービスの状態、通信のふるまい、触ろうとしている資源の重さから危険度を更新し続け、権限を段階的に変える方式を調べる。
- 入口だけの判定より、続けて確かめるほうが、異常が起きてから対処するまでの露出時間を短くする。
- 通信と身元の両方の記録を使うと、身元だけより誤った判定を抑えられる。
- 通すか止めるかの二択より、段階的に権限を下げるほうが、通信を保ちやすい。
比べるのは、固定の許可、決まった周期での見直し、出来事ごとの見直し、危険度に応じて段階を変える方式の四つである。
サービス同士の横の通信
一つの要求が複数のサービス間の通信を生む環境で、サービスの身元、mTLS、API の種類、呼び出しの連なり、遅延を結び付け、普段の依存関係から外れた通信を見つける。難しいのは、正当な自動増減や再試行を、異常な横方向の通信と取り違えないことである。
- IP と port だけより、サービスの身元と呼び出しの連なりのほうが、異常の発見に効く。
- 追跡の情報を加えると、再試行に由来する誤りを減らせる。
- 通信層と身元層の規則を合わせたものが最もよい成績を示す。
書いた方針は、その通りに効いているか
ここだけ角度が違う。クラウドごとに、仮想ネットワーク、サブネット、経路、セキュリティグループ、ファイアウォール、ゲートウェイの表し方が違う。人が設定ファイルを読むだけでは、表からデータベースへ本当に到達できるのか、インターネットから内部のサービスへ意図せず経路ができていないかを横断して確かめにくい。
そこで、各社固有の設定を共通の図と制約に変換する。点は仕事の単位、サブネット、ゲートウェイ、外部の区画。辺は経路、接続、トンネル。制約は protocol、port の分類、送り元の身元、宛先である。
そのうえで、研究者が期待する状態を宣言する。「表から API は許可」「表からデータベースは禁止」のように書く。検証する側は、クラウドの設定から計算した到達可能性とこれを突き合わせ、食い違いを返す。
評価には合成した構成を使う。正しい構成に対して一箇所ずつ設定を変え、その違反を見つけられるかを測る。実際のアカウントの秘密の設定は使わない。測るのは、到達可能性の一致、違反を見つけた割合、変換できなかった設定の書き方の割合、検証にかかる時間、図が大きくなったときの耐え方、説明の正しさ、誤って警告した数である。
ここは言語モデルとの比較が面白い
設定ファイルを言語モデルに読ませた説明と、記号的に計算した決定論的な結果を比べられる。ただし言語モデルを判定の基準には置かない。最終的な到達可能性は図の計算で決める。言語モデルは、見つかった違反を人に向けて説明する役では有用かもしれない。そこは測ってみる価値がある。
何を測るか
- 見つけた中で正しかった割合と、取りこぼさなかった割合、その調和平均
- 正常を誤って止めた割合と、止めたことで失われた通信
- 異常が起きてから権限が下がるまでの時間
- 権限が上下に揺れた回数
- 判定を続けることで増える CPU と保存量
四つ目は、この研究群に固有の物差しである。異常を早く見つけることだけを測ると、揺れの代償が表に出ない。
記録の形
実験 ID、シナリオ ID、時刻、正解ラベル、特徴量、検知器の出力、検知した時刻を最低限持つ形にそろえる。正解は実験を回す側が持ち、検知器には渡さない。結果の表は実験を回す仕組みが出した機械生成の数値から組み立て、文章を書くモデルが測定値を埋めることはしない。
差ではなく、反例を返す
方針の検証で「意図と食い違っています」とだけ返す道具は、運用では使いにくい。どこを直せばよいかが分からないからである。返すべきなのは差の有無ではなく、実際に通ってしまう経路そのものである。どの設定がその経路を許しているかまで示せて、初めて直せる。
設定の検証を論理式の充足問題として扱い、意図に反する到達が存在する場合にその具体例を取り出す枠組みは、既に査読された研究がある。Beckett らは、複数の機器の設定から到達性を記号的に計算し、反例を返す方式を示した。本研究はこの考え方を、単一の機器群ではなく事業者をまたいだ構成へ当てる。
そのうえで、変換できなかった設定の書き方の割合を必ず併記する。この数を出さない検証器は、自分が読めた範囲だけを検証して「問題なし」と言えてしまう。
予想（まだ測っていない）
出来事ごとに見直す方式が、決まった周期で見直すより、余計な評価を減らしながら重要な出来事への反応を早める可能性があると考えている。ただし手がかりが不安定なときは権限が上下に揺れるため、いったん下げたら簡単には戻さないといった作りが論点になる。
サービス間の通信では、呼び出しの連なりと身元が通信の意味を補い、通信だけを見るより誤りを減らすと予想している。ここでは観測のために増える負荷が実用性の分かれ目になる。
方針の検証では、単一のクラウドの中の到達可能性は扱えても、VPN や相互接続を跨いだときに共通の図への変換がどこまで一般化できるかが分かれ目になると見ている。
この節は仮説である。実験の後に、実測値、図表、区間推定、誤りの分析へ置き換える。
思った通りにならなくても価値がある結果
続けて確かめる方式が、入口での一度きりの判定に対して露出時間を縮めなかった場合、それは作りの複雑さに見合わないという結果になる。方針の検証では、変換できない設定の書き方が多すぎて実用にならなかった場合、どの書き方が検証を阻むのかという一覧が残る。それは次に作る人にとって、うまくいった話より役に立つ。
限界
- 小さなテスト環境と実環境の差
- データの規模と偏り
- ソフトウェアと版に依存すること
- 正常そのものが時間とともに変わること
- 記録の欠落と、機器ごとの時計のずれ
- 合成した構成が、実際のクラウドの設定の複雑さを代表しているとは限らないこと
- 変換できない設定の書き方が残ること
- 研究チームが2名であるため、初めに扱う対象を絞る必要があること
参考文献
- Rose, S., Borchert, O., Mitchell, S., Connelly, S. Zero Trust Architecture. NIST SP 800-207, 2020. DOI: 10.6028/NIST.SP.800-207.
- Chandramouli, R., Butcher, Z. A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. NIST SP 800-207A, 2023. DOI: 10.6028/NIST.SP.800-207A.
- Beckett, R., Gupta, A., Mahajan, R., Walker, D. A General Approach to Network Configuration Verification. ACM SIGCOMM, 2017. DOI: 10.1145/3098822.3098834.
- 各クラウド事業者が公開しているネットワークの方針に関する文書。
上の三件は実物の書誌を確認した。