Przejdź do treści

Tłumaczenie maszynowe. Wersja angielska jest wiążąca; weryfikacja przez native speakera jeszcze nie nastąpiła.

Produkt · Tożsamość i NHI

Nadaj każdemu agentowi własną tożsamość — i wiedz, kiedy jej nie ma

Współdzielone konto usługowe sprawia, że na pytanie „który agent to zrobił?” nie da się odpowiedzieć. Olivares wiąże agenta z tożsamością nieosobową, tworzy dedykowane NHI dla pojedynczego agenta i ujawnia agentów, którzy współdzielą jedno konto — to różnica między przypisywaniem dostępu w sposób pewny a jedynie przybliżony. Tożsamość, której nie da się rozpoznać, nigdy nie jest po cichu traktowana jak rzeczywista.

W produkcie

Konsola tożsamości

Autentyczny zrzut ekranu, dane przykładowe. Karty dla SSO/SCIM, rejestru NHI, uwierzytelniania MCP, grafu WIF, stanu kluczy i rezydencji danych oraz logowań uprzywilejowanych. Zrzut pochodzi sprzed dostarczenia backendu SSO/SCIM, więc jego karta SSO/SCIM wciąż pokazuje uczciwą informację tamtej wersji „backend w przygotowaniu” — prawdziwe ekrany, nigdy zmyślone dane.

Rzeczywisty zrzut ekranu
Konsola tożsamości Olivares: karty dla SSO/SCIM, rejestru NHI, uwierzytelniania MCP, grafu WIF, stanu kluczy i rezydencji danych oraz logowań uprzywilejowanych; na tym wcześniejszym zrzucie karta SSO/SCIM wyświetla informację o oczekiwaniu na backend zamiast zmyślonych danych.

Czym Państwo zarządzają

Od współdzielonego konta do tożsamości dla pojedynczego agenta

Tożsamość to oś, względem której mapa dostępu przypisuje działania. Dedykowane NHI dla każdego agenta zamienia „przybliżenie” w „pewność”; wszystko poniżej uczciwie informuje, jak daleko może to sięgnąć.

Powiąż lub utwórz NHI

Powiąż agenta z istniejącą tożsamością nieosobową lub utwórz dedykowane NHI dla pojedynczego agenta. To właśnie dedykowane NHI pozwala mapie dostępu przypisać dostęp w sposób pewny do jednego agenta — a nie przybliżony do puli.

Wykrycie współdzielonej tożsamości

Gdy więcej niż jeden agent korzysta z tego samego konta, przypisanie działań do konkretnego agenta jest faktycznie niejednoznaczne. Olivares ujawnia to jako wykrycie i mówi o tym wprost — nie idzie na kompromis i nie udaje, że wie, który agent działał.

Graf WIF tylko do odczytu

Graf federacji tożsamości obciążeń odwzorowuje tożsamości poszczególnych agentów na Państwa IdP. Jest renderowany w trybie tylko do odczytu na podstawie zadeklarowanych przez Państwa reguł federacji — to widok tego, co Państwo zadeklarowali, a nie weryfikacja zaufania na żywo w warstwie sieciowej.

Uczciwe „nieznane”

Tożsamość, której Olivares nie potrafi rozpoznać, jest przedstawiana jako nieznana i oznaczana — nigdy nie zostaje po cichu awansowana do nazwanego NHI. Brak sygnału tożsamości oznacza brak przypisania, co stwierdza się wprost.

Jak to działa

Federacja tożsamości pojedynczego agenta z Państwa IdP

Każdy agent otrzymuje własną tożsamość — poświadczenie SPIFFE/WIF — która federuje z Państwa dostawcą tożsamości. Agent bez możliwej do rozpoznania tożsamości nie zostaje włączony do rzeczywistej: jest przedstawiany osobno i oznaczany.

Diagram: agenci są odwzorowywani na tożsamość pojedynczego agenta (SPIFFE/WIF), która federuje z Entra ID, AWS IAM i Google Cloud; jeden agent nie ma tożsamości i jest narysowany linią przerywaną oraz oznaczony „brak tożsamości”.
Nieznany agent jest narysowany linią przerywaną i oznaczony „brak tożsamości” — nigdy nie zostaje włączony do rzeczywistego NHI. Pokazana federacja odzwierciedla zadeklarowane przez Państwa reguły.

Co jest rzeczywiste

Wiązanie NHI, sprzętowe podniesienie uwierzytelnienia i SSO/SCIM są aktywne; federacja weryfikowana na żywo nie jest

Jesteśmy w tej kwestii precyzyjni, ponieważ ta różnica to istota całej warstwy tożsamości:

  • Aktywne: wiązanie agenta z NHI, tworzenie dedykowanego NHI dla pojedynczego agenta, wykrycie współdzielonej tożsamości oraz graf WIF tylko do odczytu. Graf odzwierciedla zadeklarowane przez Państwa reguły federacji — nie jest zweryfikowanym na żywo obrazem federacji w warstwie sieciowej.
  • Dostarczone jako pobieranie tylko do odczytu: konektory rejestrów czytają rejestry tożsamości agentów głównych dostawców chmury — Microsoft Entra Agent ID, AWS Bedrock AgentCore i rejestr agentów Google. Weryfikowana na żywo federacja w warstwie sieciowej z tymi rejestrami pozostaje w planie rozwoju i nie deklarujemy jej, zanim zostanie wdrożona.
  • Dostarczone dla ludzi: podniesienie uwierzytelnienia WebAuthn/FIDO2 oraz kartą PIV/CAC przy logowaniach uprzywilejowanych, egzekwowane w trybie fail-closed — break-glass i zatwierdzenia krytyczne odmawiają poniżej zweryfikowanego sprzętowo progu AAL3, a sesja bez świeżej ceremonii jest pokazywana jako AAL1, nigdy zawyżana (NIST SP 800-63B to standard docelowy; nie deklarujemy zgodności). SSO z jednym IdP (OIDC/SAML) z zarządzaną, zapieczętowaną konfiguracją oraz provisioning SCIM użytkowników i grup należą do otwartej wersji; federacja multi-IdP per tenant i wymuszone SSO to Enterprise.

Tożsamość i NHI — pytania

Czy Olivares federuje dziś na żywo z Entra Agent ID, AWS AgentCore lub Google Agent Identity?

Nie jako zweryfikowane na żywo zaufanie. Konektory tylko do odczytu pobierają te rejestry agentów jako migawki, a sam graf WIF jest renderowany na podstawie zadeklarowanych przez Państwa reguł federacji — pokazuje to, co Państwo zadeklarowali, i to, co raportują rejestry, a nie zweryfikowaną na żywo relację zaufania w warstwie sieciowej. Federacja na żywo z tymi rejestrami jest w planie rozwoju i nie deklarujemy jej, zanim zostanie wdrożona.

Dwóch agentów współdzieli jedno konto usługowe. O którym z nich Olivares powie, że działał?

O żadnym z całą pewnością. Współdzielona tożsamość sprawia, że przypisanie działań do konkretnego agenta jest faktycznie niejednoznaczne, więc Olivares zgłasza wykrycie współdzielonej tożsamości i przypisuje dostęp jedynie w sposób przybliżony — nie będzie z całą pewnością twierdził, że działał konkretny agent. Utwórz dedykowane NHI dla pojedynczego agenta, a mapa dostępu będzie mogła przypisać działania temu agentowi w sposób pewny.

Czy obsługują Państwo podniesienie poziomu uwierzytelnienia do WebAuthn AAL3 lub PIV-CAC przy logowaniach uprzywilejowanych?

Tak. Sesja uprzywilejowana podnosi uwierzytelnienie przez WebAuthn/FIDO2 lub certyfikat karty PIV/CAC do zweryfikowanego sprzętowo progu AAL3 z NIST SP 800-63B — to standard docelowy; nie deklarujemy zgodności z NIST ani FIPS. Podniesienie działa w trybie fail-closed: wygasa po krótkim oknie świeżości, sesja bez zweryfikowanej ceremonii jest pokazywana jako AAL1, a break-glass i zatwierdzenia krytyczne odmawiają kontynuacji poniżej AAL3.

Czy dostarczają Państwo SSO i provisioning SCIM?

Tak. Otwarta wersja dostarcza SSO z jednym IdP (OIDC i SAML) z zarządzaną konfiguracją opartą na magazynie — sekrety zapieczętowane w spoczynku, zapisy konfiguracji chronione podniesieniem AAL3 — plus provisioning SCIM użytkowników i grup. O tym, co może nadawać grupa katalogowa, decyduje operator: mapowań ról nigdy nie da się zapisać od strony IdP. Federacja multi-IdP per tenant i wymuszona polityka SSO to możliwości Enterprise.

Nadaj swoim agentom tożsamości, które możesz przypisać

Wdróż Olivares na własnej infrastrukturze, utwórz dedykowane NHI dla każdego agenta i zamień „przybliżenie” w „pewność” na swojej mapie dostępu.