プロダクト · アクセスマップ
各エージェントが到達できる範囲を可視化 — 読み取りと書き込みを区別
すべてのエージェント、セッション、アイデンティティについて、アクセスマップは接触したリソースを表示し、読み取りと書き込みを分離し、実際のアクセスが許可した内容から乖離した瞬間を検知します。すでに保有しているシグナルからパッシブに検出し、データ経路にプロキシは介在しません。
プロダクト内
実際のコンソールから見たマップ
サンプルデータを投入したOlivaresコンソールの実際のスクリーンショットです。左側がオリジン、右側が接触したリソースで、読み取り、書き込み／RW、不明、概算で色分けされています。マップを開く操作は特権かつ監査対象であり、表示するのは関係性のみで、SQL、ペイロード、シークレットは一切表示しません。
モデル
読み取り、書き込み、そして正直な「不明」
Olivaresは各アクセスをコネクタ側で、ステートメントや動詞そのもの（SQLの種別、HTTPメソッド、MCPツールのセマンティクス、ファイルのオープンモード）から分類します。記録するのは関係性だけであり、ステートメント自体は記録しません。SQLテキストもパラメータもペイロードもシークレットも保持しません。
読み取り
リソースを読み取るだけのエージェント — SELECT、GET、読み取り専用のツール呼び出しです。落ち着いた中立色で描画されます。
読み取り／書き込み
リソースを変更できるエージェント — INSERTやUPDATE、書き込み系のツール、状態を変える呼び出しです。影響範囲を左右するエッジです。
不明 · 概算
ストアがアイデンティティ単位の監査を提供しない場合や、シグナルが弱い場合、Olivaresはそれを正直に示します。確実性を捏造する代わりに、点線で控えめに描画したエッジで表現します。
最小権限からの逸脱
許可済み vs 観測済み — 本当に重要な発見
逸脱とは、付与したアクセスと実際に発生しているアクセスとのギャップです。Olivaresは、あるエージェントに帰属する観測を、そのエージェントが実際に使うアイデンティティと突き合わせて照合し、3つの正直な状態を提示します。
- 想定外のアクセス
観測されたが、一度も許可されていないアクセス。背後に何の付与もないまま発生しているアクセスであり、最優先で対処すべき発見です。
- 照合保留中
対応する付与なしに観測されたものの、エージェントとアイデンティティの紐付けがまだ確定していません。確定した違反としてではなく保留中として提示します。捏造した警報ではなく、正直な不確実性です。
- 未使用の付与
許可されているが、一度も観測されていないアクセス。引き締めるべき過剰なプロビジョニングであり、もう一方の側面から見た最小権限です。
仕組み
付与と観測から単一の判定へ
Olivaresは、許可した内容と観測した内容を取り込み、オリジンをまたいで照合し、その結果を描画します。一致、逸脱、あるいは宣言できるだけの関係性であり、見たふりをすることは決してありません。
正直に示すカバレッジ
2つの忠実度の軸 — どちらも偽りません
リソースをどれだけ監査できるかと、アクセスを特定のエージェントにどれだけ確実に結びつけられるかは、別物です。Olivaresはノードごとに両方を示し、推測する代わりに段階的に劣化させて表現します。
リソースカバレッジ
リソースそのものをどれだけ完全に監査できるか。
- クリーン
- ネイティブ監査 — PostgresのpgAudit、AWS CloudTrailなど。アクセス単位で完全な忠実度が得られます。
- 不完全
- ドキュメントストアやベクトルストア：シグナルは部分的で、部分的なものとして表示します。切り上げて誇張することはありません。
- 不透明
- Redis、SQLite、D1などはアイデンティティ単位の監査を提供しません。不透明としてマークし、黙って格上げすることはありません。
オリジンの帰属
アクセスを特定のエージェントにどれだけ確実に結びつけられるか。
- 確実
- 専用の非人間アイデンティティ — エージェントごとに発行されるSPIFFE/WIF認証情報です。実線で描画されます。
- 概算
- 共有またはプールされたアカウント：アクセスは実在しますが、エージェントは曖昧です。点線で描画し、概算としてラベル付けします。
- 不明
- アイデンティティのシグナルがまったくありません。控えめに表示し、名前付きのエージェントへ格上げすることは決してありません。
2つの軸は独立しています。不透明なストアへのアクセスでも、協調するシグナルがエージェントを特定していれば、確実に帰属させられます。Olivaresがしないのは、概算や不明を確実であるかのように描画することです。
実際に動くもの
構築・検証済み — そして限界についても正直に
アクセスマップは技術的な概念実証のゲートを通過しており、グラフの書き手となります。2つの正直な注記があります。
- マップを開く操作は特権かつ監査対象であり、すべてのクエリは追記専用の台帳にエントリを封印します。これは防御的なレビューのためのものであり、扱うのは関係性であって中身ではありません。
- 忠実度はソース次第です。ネイティブ監査（pgAudit、CloudTrail）とエージェント単位のアイデンティティを接続すればマップは最も鋭くなります。それらがなければ、Olivaresは自信ありげな作り話ではなく、忠実度の低い段階を示します。
アクセスマップ — よくある質問
プロキシやインラインエージェントは必要ですか？
いいえ。Olivaresは、すでに保有しているシグナル（ネイティブのデータベース監査、クラウド監査ログ、OpenTelemetry、eBPF、MCPイントロスペクション）からアクセスをパッシブに検出します。データ経路に必須のプロキシは存在せず、世話をするものもありません。
マップはSQL、ペイロード、シークレットを保存しますか？
いいえ。各アクセスは動詞（SQLの種別、HTTPメソッド、ツールのセマンティクス）から分類され、関係性（オリジン、リソース、読み取りか書き込みか）として記録されます。ステートメントのテキスト、パラメータ、ペイロード、シークレットは一切取得しません。
Redisのように、アイデンティティ単位の監査がないストアはどうなりますか？
それらは不透明なカバレッジとしてマークされます。Olivaresは実際に証明できる忠実度で関係性を示し、その限界をラベル付けします。ストアが裏付けられないアイデンティティ単位の帰属を捏造することはありません。
読み取りと読み取り／書き込みをどのように見分けますか？
ステートメントや動詞そのものから、コネクタ側で分類します。SELECT に対する INSERT や UPDATE、GET に対する状態を変えるメソッド、読み取り専用に対する書き込み系のツール呼び出しといった具合です。エッジの色がそれに従います。読み取り、書き込み／RW、そしてシグナルが弱い場合は不明です。
あなた自身のアクセスマップを見る
Olivaresを自社のインフラにデプロイし、監査ソースを指定すれば、プラットフォームチームとセキュリティチームが求めてきた読み取り／書き込みマップが手に入ります。