Poznámky k verzím¶

Historie verzí platformy MazeVault

Verze dokumentu: 1.0.61 Poslední aktualizace: 2026-10-28

Verze 1.0.61¶

Datum vydání: Nevydáno

Změny distribuce (vyžadují akci)¶

Zařízení HSM typu PKCS#11 vyžadují HSM_PKCS11_MODULES (nastavte před aktualizací) — Server nově načítá jen knihovny PKCS#11, které provozovatel uvede v nové proměnné HSM_PKCS11_MODULES (čárkou oddělené absolutní cesty tak, jak je vidí kontejner backendu). Ve výchozím stavu je prázdná, což odmítne každé zařízení HSM typu PKCS#11: po aktualizaci test spojení, kontrola stavu i směrování klíčů hlásí takové zařízení jako nedostupné, dokud není jeho modul uveden, a log při startu vypíše dotčená zařízení. Zákazníci, kteří zařízení PKCS#11 používají, musí proměnnou nastavit (.env, Compose nebo Helm backend.config) před aktualizací.
Politika verzí agenta nahrazuje proměnné prostředí s verzí agenta — Jakou verzi agenta který agent dostane, nově určuje politika verzí (Nasazení → Agenti → Politika verzí). AGENT_VERSION, AGENT_MAX_ALLOWED_VERSION a AGENT_ROLLOUT_PERCENTAGE jsou zastaralé: jednou při prvním startu primary naplní prázdnou politiku (pozdější změny jen zapíší varování o zastarání). Přišpendlené hodnoty se stanou cílovými verzemi a stropem, takže agentům s vyšší verzí bude nabídnut downgrade na ně — pokud to nechcete, smažte cíle/strop v politice nebo nastavte minimální verzi pro rollback. Gatewaye se řídí politikou z primary. Nová spodní hranice pro rollback agenta min_rollback_version omezuje, jak daleko lze agenta vrátit; zrušit ji lze příkazem reset-min-rollback-version.
Image, Helm chart a Compose kit se přesouvají do MazeVault Harboru — Od tohoto releasu se MazeVault distribuuje jen z registry.mazevault.com: image registry.mazevault.com/mazevault/mazevault-{backend,frontend,edge,docs,ocsp,init-certs}:vX.Y.Z, Helm chart oci://registry.mazevault.com/mazevault/mazevault-customer (verze X.Y.Z) a Compose kit (instalátor, upgrade/rollback skripty, docker-compose.yml, .env.example, SHA256SUMS) jako OCI artefakt registry.mazevault.com/mazevault/compose-kit:vX.Y.Z, který se stahuje přes oras pull (skripty spouštějte přes bash, ORAS nezachovává příznak spustitelnosti). Každý zákazník dostane robot účet jen pro čtení; GitHub token ani stahování z raw.githubusercontent.com už nejsou potřeba. v1.0.60 a starší zůstávají na GHCR (ghcr.io/mazevault); stávající instalace si ponechají IMAGE_REGISTRY, dokud ho výslovně nezměníte (install-mazevault.sh --registry nebo hodnoty image.repository v chartu).
Online instalátor používá docker-compose.yml z kitu — install-mazevault.sh už nezapisuje vlastní vloženou kopii compose souboru; nainstaluje docker-compose.yml, který leží vedle něj v Compose kitu (stejně jako už to dělal install-mazevault-offline.sh), a když chybí, skončí chybou, proto ho spouštějte z rozbaleného kitu. Online instalace znovu spuštěné s tímto releasem tak převezmou nastavení z kitu, např. MAZEVAULT_ENV_CANONICAL_ENFORCE (výchozí false); MAZEVAULT_CUSTOMER_NAME, MAZEVAULT_CUSTOMER_EMAIL a MAZEVAULT_COMPANY_ID musí být v .env neprázdné (instalátor je generoval vždy). Compose soubor z kitu přebírá health check backendu z kopie v instalátoru a frontend startuje, až je backend zdravý. Nové přepínače pro automatizaci: MAZEVAULT_NO_SYSTEMD=1 přeskočí systemd službu i všechna volání systemctl a MAZEVAULT_COMPOSE_PROJECT přepíše název projektu Compose (výchozí mazevault). Nově vygenerovaná systemd jednotka předává název projektu (-p) příkazům up i down; jednotka se generuje jen tehdy, když neexistuje, takže stávající /etc/systemd/system/mazevault.service si ponechá původní příkaz (pro přegenerování ji smažte a instalátor spusťte znovu).
Vygenerované stacky pro gateway stahují backend z MAZEVAULT_IMAGE_REGISTRY (výchozí MazeVault Harbor) ve verzi primary a při instalaci vyžadují MAZEVAULT_GATEWAY_ENVIRONMENT.
Customer Helm chart — prostředky External Secrets používají external-secrets.io/v1 (vyžaduje External Secrets Operator 0.16 nebo novější); backend za ingressem běží přes HTTP (MAZEVAULT_TLS_ENABLED=false); přístupový klíč Redisu je v REDIS_URL URL-kódovaný.
API pro nasazení agentů — os_type: darwin a agent_mode: gateway|sidecar se odmítají s HTTP 400; podporovaní agenti jsou Linux a Windows.
Helm: bffSharedSecret je povinný a ingress musí směrovat /api, /swagger a /health na backend — Nové webové rozhraní potřebuje sdílené tajemství s backendem. Vytvořte ho v Key Vaultu (openssl rand -base64 48 | tr -d '\n/+=') a před helm upgrade zadejte jeho název do global.keyVault.secretKeys.bffSharedSecret; dokud je frontend.enabled pravda, chart se bez něj nevykreslí. Frontend už neproxuje /api: ingress z chartu posílá /api, /swagger a /health na backend a / na frontend (port kontejneru 3000, port Service zůstává 80); vlastní ingress musí dělat totéž. Pokud pody ingress controlleru nejsou v privátním rozsahu, nastavte backend.config.TRUSTED_PROXIES na jejich CIDR.
Importovaný certifikát potřebuje svůj řetězec — Server webového rozhraní ověřuje backend přes /certs/ca-bundle.crt. import-cert.sh a renew-certs.sh nově tento soubor skládají jako list plus řetězec CA a varují, když řetězec nebyl zadán (svazek je pak jen list a webové rozhraní backend neověří). Importujte znovu s řetězcem: ./import-cert.sh cert.pem key.pem ca-chain.pem. Při startu kitu se existující ca-bundle.crt zachová a chybějící se vytvoří ze server.crt, i s MAZEVAULT_TLS_SKIP_INIT=true a ručně vloženým certifikátem.
Docker Compose: převezměte nový kit — upgrade-mazevault.sh po zálohování nainstaluje docker-compose.yml z kitu. Spusťte upgrade skript dodaný v novém kitu (oras pull registry.mazevault.com/mazevault/compose-kit:vX.Y.Z -o mazevault-kit, poté sudo bash mazevault-kit/upgrade-mazevault.sh --version vX.Y.Z), u offline aktualizace předejte nový balík přes --offline (nainstaluje se i jeho docker-compose.yml); ne kopii v instalačním adresáři. Se starším docker-compose.yml (bez služby edge) se skript zastaví dřív, než cokoli změní, a vypíše správný příkaz. Ten přidává kontejner edge (viz Nové funkce) a znovu vytvoří síť Compose frontend s pevnou podsítí MAZEVAULT_SUBNET (výchozí 172.31.250.0/24), takže počítejte s krátkým výpadkem. Pokud docker compose up změněnou síť odmítne, spusťte docker compose down (bez -v) a poté docker compose up -d. Pokud se aktualizace zastaví kvůli překryvu podsítě s jinou sítí Dockeru nebo trasou hostitele (původní stack dál běží: „The stack was not touched.“), nejprve nastavte v .env volnou MAZEVAULT_SUBNET. Neověřitelná kontrola jen varuje „NOT checked“ a pokračuje. Skript se také zastaví před přepnutím, když server.crt instalace neobsahuje NUXT_CORE_API_SERVERNAME (výchozí MAZEVAULT_DOMAIN), protože webové rozhraní by backend neověřilo; zpráva uvádí, jak to opravit.
Výchozí TRUSTED_PROXIES v Docker Compose se zužuje na podsíť kitu — Externí load balancer před edge v jiném privátním rozsahu musí nastavit TRUSTED_PROXIES v .env; jinak se jeho X-Forwarded-For ignoruje a IP klienta v auditním logu a v rate limitech bude IP proxy. Výchozí hodnoty backendu a Helmu se nemění (loopback a privátní rozsahy).
Proměnné webového rozhraní — Kontejner frontendu čte NUXT_CORE_API_URL (URL backendu), NUXT_BFF_SECRET (z BFF_SHARED_SECRET), volitelnou NUXT_CORE_API_SERVERNAME (název v certifikátu backendu, pokud se liší od hostitele v URL) a NODE_EXTRA_CA_CERTS (balík CA, kterým se backend ověřuje); viz Proměnné prostředí. Vlastní FRONTEND_PORT s FRONTEND_URL bez tohoto portu vyvolá varování s přesným řádkem NUXT_PUBLIC_ORIGIN=<base>:<port>, který přidejte do .env (nenastavuje se automaticky: za proxy na 443 port správně chybí); oba instalátory při nové instalaci přidají port do FRONTEND_URL a ALLOWED_ORIGINS (offline instalátor bere FRONTEND_PORT z prostředí). DOCS_URL je přejmenováno na NUXT_PUBLIC_DOCS_URL; kit pro tento release čte i DOCS_URL. IP adresa jako MAZEVAULT_DOMAIN: BFF ověřuje certifikát backendu podle NUXT_CORE_API_SERVERNAME (výchozí MAZEVAULT_DOMAIN) a IP adresa odpovídá jen položce IP v certifikátu, proto instalátory a upgrade-mazevault.sh přidají do .env NUXT_CORE_API_SERVERNAME=localhost a init-certs přidá do nových certifikátů IP:<doména> (viz Konfigurace TLS).

Nové funkce¶

Nové webové rozhraní (Nuxt) se serverovým BFF — Aplikaci React nahrazuje nové webové rozhraní s malým serverem (BFF) v kontejneru frontendu. Prohlížeč drží jen cookie __Host-session (Secure, HttpOnly, SameSite=Strict); v prohlížeči není žádný JWT a BFF ke každému požadavku připojí serverovou relaci. Přihlášení: lokální, LDAP / AD, Kerberos (záložka se zobrazí, jen když GET /api/v1/auth/sso/spnego/status hlásí dostupnost) a tlačítko SSO Entra ID; tlačítko Google zmizelo, protože backend pro něj nemá trasu. Po přihlášení s MFA stačí jedno pole pro TOTP nebo záložní kód; příliš mnoho pokusů nebo vypršelé čekající přihlášení vrátí na /login s upozorněním. Uživatel s must_change_passwd je přesměrován na /change-password a relaci si ponechá. Vypršená relace pošle uživatele na /login?redirect=<stránka> a po dalším přihlášení zpět. Každá stránka kontroluje svoje oprávnění: bez něj zobrazí „Access Denied“ s chybějícím oprávněním a postranní menu položku skryje. Relace prohlížeče nejsou autentizační metodou API pro integrace.
Světlý a tmavý režim — Webové rozhraní se řídí světlým nebo tmavým vzhledem operačního systému a přepínač v horní liště ho může změnit; volba se pamatuje v prohlížeči.
Šifrované názvy tajemství po lokálním přihlášení — Šifrované názvy tajemství se odemknou po lokálním přihlášení heslem (ne přes LDAP, Kerberos ani SSO). Neúspěšné odemknutí zanechá jedno varování („Encrypted secret names are unavailable in this session.“). Klíč drží pro každého uživatele service worker prohlížeče a po obnovení stránky se obnoví nejdéle na 2 hodiny; při vypršení relace se vymaže. Jde o šifrování názvů a hodnot tajemství dat v2 na straně klienta klíčem odvozeným z lokálního hesla, nikoli o úložiště se zero-knowledge: přihlášení posílá heslo serveru.
Edge kontejner — Compose kit přidává kontejner mazevault-edge (nginx). Ukončuje TLS na 443 a 80 (80 přesměrovává na HTTPS) a směruje /api/ a /swagger na backend a / (stránky a /bff) na frontend; frontend už TLS neukončuje. Edge je zabezpečený (no-new-privileges, všechny capabilities zrušeny, souborový systém jen pro čtení, výchozí 64 MB přes EDGE_MEMORY_LIMIT) a skripty pro certifikáty ho po importu nebo obnovení restartují.
OpenAPI 3.1 na /swagger — /swagger servíruje dokument OpenAPI 3.1 (/swagger/doc.json) se Swagger UI 5 (/swagger/index.html). Trasy, které v dokumentu nejsou typované (ACME, OCSP, SCEP, CRL, export certifikátu, websocket agenta, binární soubory ke stažení, health a samotný Swagger; celkem 28), jsou vypsány v popisu dokumentu. SWAGGER_ENABLED a SWAGGER_HOST platí jako dosud.
Dlouhé operace mají dál limit 300 sekund — Požadavek přes webové rozhraní smí trvat 300 sekund (poté BFF odpoví 504 backend timeout; proxy_read_timeout a proxy_send_timeout na edge jsou 300 s směrem k backendu a čtení směrem k webovému rozhraní 310 s, aby 504 od BFF dorazila první; websocket agenta 3600 s, nahrávání do 50 MB). Selhání mezi BFF a backendem vrací 502 a BFF loguje jen kód příčiny.
Přidaná potvrzení — Webové rozhraní nově žádá o potvrzení před schválením nebo zamítnutím žádosti o heslo, obnovením certifikátu, schválením CSR na stránce Objevené certifikáty, vygenerováním klíče ACME EAB a exportem certifikátu se soukromým klíčem.
Efektivní řetězec certifikátu: podřízené CA se exportují včetně rootu — Export podřízené CA (nebo jakéhokoliv certifikátu) importované bez řetězce vydavatelů nyní automaticky obsahuje vydávající CA i root, pokud je vydavatel přítomen v inventáři organizace. Nový CertificateChainResolver je jediným zdrojem pravdy pro efektivní řetězec: řetězec zachycený na záznamu při importu nebo vydání se vrací byte po bytu a nikdy se nerozšiřuje; pouze certifikáty bez uloženého řetězce se doplňují z CA certifikátů spravovaných v téže organizaci (včetně interní CA a explicitní vazby záznamu na CA) a kandidát je přijat výhradně tehdy, když kryptograficky ověří podpis certifikátu — shoda Distinguished Name sama o sobě dva certifikáty nikdy nepropojí. Root se zahrnuje, archivovaní kandidáti se ignorují, revokovaný vydavatel se použije jen tehdy, když nic jiného neověří, a je hlášen jako varování; vydavatelé s nebezpečným podpisovým algoritmem jsou odmítnuti s varováním. Tentýž řetězec používá export API (include_chain=true, všechny formáty), detail certifikátu (záložka Chain nově zobrazuje původ — Stored with certificate / Resolved from inventory / No chain — plus úplnost k rootu a varování), seznam certifikátů pro agenta i Terraform data source, takže všichni konzumenti vidí identický materiál. Čtení nikdy nezapisuje do databáze; řetězec se persistuje jen tehdy, když import nebo adopce zapisuje tělo certifikátu bez řetězce. Odpověď GET /certificates/{id} získává chain_source, chain_complete a chain_warnings; data source mazevault_certificate získává chain_pem, chain_source a chain_complete a jeho atribut certificate_pem — dříve mapovaný na pole, které API nikdy nevracelo — je nyní naplněn z public_chain_pem. Nová Prometheus metrika: mazevault_certificate_chain_resolution_total{source,complete}.
Objevené certifikáty si uchovávají tělo; adopce dává nasaditelný certifikát — Discovery agentem nyní ukládá veřejný leaf certifikát a řetězec vydavatelů, který agent viděl (migrace 000199, sloupce certificate_pem / chain_pem v discovered_certificates; pouze veřejný materiál, nikdy klíč). Adopce objeveného certifikátu proto vytvoří spravovaný certifikát s tělem, které lze exportovat, nasadit a ověřit; spravované certifikáty adoptované před touto verzí dostanou tělo automaticky při příštím skenu agenta přes stávající auto-link podle otisku, a nahlášený řetězec se ukládá tak, jak je (z inventáře se doplňuje jen tehdy, když agent žádný nenahlásil). Detail objeveného certifikátu (GET /discovered-certificates/{id}) vrací certificate_pem, chain_pem a chain_certificates; seznamy tělo záměrně vynechávají, aby stránka Discovered Certificates zůstala rychlá. Identita (serial, otisky) se nyní odvozuje z DER certifikátu místo důvěry v hlášení agenta.
Tělo certifikátu ze synchronizace s CA a z ručního importu — Tělo se nyní uchovává i u certifikátů synchronizovaných z výpisu CA (HashiCorp Vault, DigiCert, ADCS, SSLMarket a lokální inventář pro ACME / I.CA / PostSignum): ParseCertificateMetadata přenáší normalizované PEM do objeveného záznamu, opakovaná synchronizace s CA doplní tělo záznamům vytvořeným dříve bez něj a spravovaný certifikát navázaný podle otisku, který tělo nemá, ho dostane stejně jako u agentní cesty. Navíc import samotného veřejného certifikátu (CRT/PEM/DER nebo PFX) nyní doplní spravovaný certifikát bez těla místo odmítnutí jako „již existuje“: import se spáruje podle otisku (nebo přiváže přes expected_certificate_id z detailu certifikátu), tělo se uloží spolu s identitou a popisnými sloupci odvozenými z něj (kanonický serial, otisky, subjekt/vydavatel, platnost, algoritmy klíče a podpisu, key usage, SAN, typ certifikátu; stav active se aktualizuje, revokovaný či čekající se nikdy nemění) a záznam bez řetězce se doplní z inventáře. Privátní klíč se u takového záznamu řídí schváleným pravidlem: klíč dodaný spolu s certifikátem se připojí, pokud záznam custody nemá; klíč shodný s existující custody je idempotentní opakovaný import; klíč, který neodpovídá, je odmítnut s explicitní chybou až po uložení těla — záznam nikdy nezůstane bez těla kvůli špatnému klíči. Lokálně uložený klíč, který při svém importu nešlo ověřit (záznam neměl tělo), se ověří při doplnění těla a pokud k certifikátu nepatří, je označen (metadata.private_key_mismatch, auditní událost certificate.private_key_mismatch), ale nikdy nesmazán. Položky hromadného/souborového importu v tomto případě vrací message: "existing certificate record completed with the uploaded certificate body"; detail certifikátu zobrazuje akci Complete certificate u záznamů bez těla a detail objeveného certifikátu vysvětluje ruční cestu. Discovery ingest, synchronizaci s CA, adopci i import nyní obsluhuje jedna sdílená implementace (applyCertificateBodyToManaged), takže každá cesta dává stejně kompletní záznam (dřívější cesta re-skenu nastavovala key usage jen v paměti a neukládala ho).
Nasazení do souborů přes agenta a allowlistované příkazy — Rotace certifikátu nyní umí nasazovat do souborů na hostiteli agenta (cíl Agent File (PEM), krok agent_file_sync): agent zapíše leaf, řetězec, klíč a volitelný sloučený bundle (PEM nebo PKCS#12) podle content mode cíle (public_only, public_chain, full_chain_with_key, key_only), nastaví práva a vlastníka, původní soubory ponechá jako .BAK, nainstaluje řetězec do trust store platformy (je-li zapnuto) a spustí volitelný post-install příkaz. Kroky rotace, které potřebují příkaz na hostiteli (restart služby, WLST restart skript, Oracle orapki), nyní běží přes nový požadavek agenta agent_command, který spouští pouze příkazy odpovídající vestavěnému allowlistu agenta nebo regulárnímu výrazu v allowed_commands konfigurace operátora. Cíle Oracle database wallet se nyní nasazují skutečně: PKCS#12 s jednorázovým heslem se připraví pod <wallet>/mazevault/, importuje přes orapki wallet import_pkcs12 (auto-login nebo heslem chráněné wallety přes wallet_password_ref) a vždy se následně odstraní; heslo walletu i PKCS#12 jsou označena jako citlivá, takže je agent v auditním logu, odpovědi i případné chybě odmítnutí rediguje, a staging krok nenese idempotency klíč, aby opakovaná rotace soubor znovu připravila místo přehrání zastaralého výsledku. update_tns_names a rac_nodes jsou explicitně odmítnuty místo ignorování. Cíle WebLogic se nyní nasazují přes skutečný krok weblogic_deploy: leaf a klíč se nainstalují do custom identity keystore (JKS nebo PKCS#12, záloha přes backup_enabled), řetězec vydavatelů se volitelně importuje do custom trust keystore (trust_store_path + nové trust_store_type / trust_store_password_ref; každý vydavatel se připraví jako samostatný PEM pod <adresář-trust-store>/mazevault/, importuje přes keytool -importcert -trustcacerts, již existující alias se počítá jako úspěch a připravený soubor se vždy odstraní) a managed server nebo cluster se volitelně restartuje přes wlst_script_path operátora (restart_mode graceful / force / rolling). Heslo trust store je označeno jako citlivé, takže ho agent všude rediguje, a administrátorské přihlašovací údaje se nikdy nedostanou na příkazový řádek — WLST skript musí používat uložené přihlašovací údaje; admin_url, server_name a cluster_name jsou odmítnuty, pokud obsahují shellové metaznaky, a režim restartu vyžaduje admin_url. Strukturované požadavky agent_command (keytool, orapki, WLST skript) agent spouští přímo s vektorem argumentů, bez shellu, takže heslo obsahující shellové metaznaky nemůže být shellem ani reinterpretováno, ani vypsáno zpět; citlivé hodnoty jsou navíc před odesláním z agenta vyčištěny z výstupu příkazu i textu chyby. Operátorem zadané post-install příkazy si zachovávají shellovou sémantiku.
Cíle nasazení se validují při uložení — Vytvoření nebo úprava cíle nasazení certifikátu se nyní validuje proti tomu, co systém skutečně umí provést, a vrací 400 s důvodem místo přijetí konfigurace, která by později selhala nebo byla přeskočena: cíle přes agenta (agent_keystore, agent_file, database, weblogic) vyžadují agenta; cíl database wallet vyžaduje wallet_path, provider Oracle (SQL Server, PostgreSQL, MySQL a MongoDB žádný wallet nemají — chyba uvede cíl Agent Keystore / Agent File, který se má použít místo něj) a update_tns_names=false; cíl WebLogic vyžaduje keystore_path, referenci na heslo pro svůj trust store a WLST skript pro jakýkoliv režim restartu; cíle web_server a load_balancer jsou odmítnuty s podporovanou alternativou, protože pro ně zatím neexistuje mechanismus nasazení. Stejnou validaci aplikuje builder workflow, takže zapnutý cíl, který nelze provést, rotaci ukončí chybou s ID cíle a důvodem místo tichého přeskočení. Vypnutí nebo změna priority existujícího cíle s neplatnou starší konfigurací je vždy povoleno, aby ho operátor mohl z rotace vyřadit; opětovné zapnutí vyžaduje opravu konfigurace. Editor cílů rotace v UI tato pravidla zrcadlí: Database Wallet vyžaduje agenta a je označen Oracle, ne-Oracle providery a přepínač Update TNS Names jsou zakázány s vysvětlujícím textem, Web Server se zobrazuje jako zatím nedostupné a Load Balancer je pro nové cíle z výběru skrytý (existující se stále otevře v režimu úprav s vysvětlením, aby šel vypnout nebo smazat — z API ani z kódu nebylo nic odstraněno), při odmítnutém uložení se zobrazí důvod z backendu a seznam cílů získal akci Zapnout / Vypnout, která mění pouze příznak enabled — cesta, jak starší cíl z rotace vyřadit bez smazání.
Zálohy rotace tajemství: retence, úklid a ruční obnova — Každá rotace tajemství pořizuje šifrovanou zálohu stavu před rotací a nyní ji sleduje explicitním životním cyklem (pending → released / restored / recovery_required → acknowledged). Denní úklidová úloha maže pouze zálohy v terminálním stavu po vypršení retenčního okna, zatímco zálohy, u nichž selhal automatický rollback, jsou označeny recovery_required a nikdy se automaticky nemažou. Operátoři mohou zálohy vypsat, obnovit nebo odhalit hodnotu před rotací a potvrdit vyřešenou zálohu přes nové rotation API endpointy: GET /rotation/backups, POST /rotation/backups/{id}/restore, POST /rotation/backups/{id}/reveal a POST /rotation/backups/{id}/acknowledge. Reveal a restore navíc v handleru vynucují secret:read na prostředí daného tajemství a pro externě spravovaná (orchestrator mód / names_only) tajemství se lokálně žádná hodnota neukládá ani nevrací — operátor je odkázán na získání hodnoty z externího provideru pod vlastní identitou, takže API nemůže obejít řízení přístupu ke Key Vaultu. Retence je konfigurovatelná novou proměnnou MAZEVAULT_ROTATION_BACKUP_RETENTION_DAYS (výchozí 7). Byly přidány dvě metriky Prometheus: mazevault_rotation_backups_purged_total a mazevault_rotation_backups_recovery_required.
Preflight rotace nyní před spuštěním ověřuje připravenost gateway a agentů — Preflight engine rotace i orchestrátor nyní před povolením startu rotace vyhodnocují živou připravenost každého požadovaného cíle exekuce — gateway a post-action agentů — namísto pouhé kontroly konfigurace. Nová metoda ProbeGatewayByID prověří konkrétní gateway podle ID a nemutující cesta EvaluateReadiness posoudí, zda je rotační zdroj připraven, aniž by měnila jakýkoli stav. Preflight engine rozlišuje povinné a volitelné post-action agenty, takže rotace závislá na nedostupné gateway nebo nedostupném povinném agentovi je klasifikována a nahlášena předem (napájí výsledky ready / deferred / blocked / manual-review-required) místo selhání uprostřed běhu. Rotační plánovač v rámci této práce efektivněji klasifikuje chyby brány (gate).
Revoker milostivé lhůty pro service identity — Nová úloha na pozadí tvrdě revokuje tajemství klientů (service identit), jejichž lhůta milostivé doby (grace period) vypršela, a dokončuje tak cestu „soft revokace“, kterou RotateClientSecret zahajuje při nakonfigurované grace period. Dříve se zrotované tajemství s grace oknem spoléhalo na to, že staré přihlašovací údaje zůstanou platné, ale nic je po vypršení okna durabilně nevyřadilo. Revoker běží periodicky z plánovače (výchozí jednou za minutu), materializuje vypršelé grace periody a pro každou tvrdou revokaci zapíše auditní záznam.
Správa životního cyklu agentů a evidence deployment záznamů — Registrované agenty lze nyní spravovat v celém životním cyklu řídicí roviny přímo v sekci Nasazení → Agenti a autentizace agentů je od začátku do konce lifecycle-aware. Nový route guard RequireActiveAgent při každém JWT-autentizovaném požadavku agenta znovu ověří aktuální stav agenta v databázi, takže agent, který byl odregistrován, revokován nebo smazán, už nemůže volat agentní routy s neexpirovaným tokenem; registrace ani legacy hostname-discovery cesta už neaktivují neaktivního ani revokovaného agenta a runtime konzumenti (resolvování rotačního sync-targetu, SSH deploy/revoke, keytab rotace) odmítnou směrovat práci přes neaktivního agenta. Konzoli obsluhují čtyři nové agent:admin endpointy: GET /api/v1/agents/:id/lifecycle-impact vrací orientační přehled závislostí (spravované certifikáty, vazby na projekty, rotační cíle, SSH klíče, čekající keytab práce, discovery/config/token reference) s best-effort varováními; POST /api/v1/agents/:id/unregister vyřadí agenta — zneplatní jeho mTLS identitu a recovery tokeny, deaktivuje vazby na projekty a označí čekající keytab práci jako selhanou — nebo povýší na bezpečnostní revokaci, pokud je kategorie důvodu compromised / lost_credential / stolen_host, přičemž nevyřešené blockery vyžadují force; POST /api/v1/agents/:id/reregister vyřadí starou identitu a vydá jednorázový 24hodinový náhradní bootstrap token; a POST /api/v1/agents/:id/uninstall požádá připojeného schopného agenta, aby se sám odinstaloval. Vzdálená odinstalace se vyjednává podle schopností v době požadavku a je podporována pro Linux balíčkové (systemd) instalace běžící jako root a Windows MSI service instalace: agent nejprve potvrdí přijetí, poté odpojená kopie agentní binárky (uniká z cgroup služby přes systemd-run na Linuxu, DETACHED_PROCESS na Windows) provede odstranění a před sebe-zničením nahlásí skutečný výsledek zpět přes health kanál — na Windows se per-build MSI ProductCode zjistí za běhu ze stabilního WiX UpgradeCode a odebere přes msiexec, s fallbackem sc delete pro ne-MSI service rozložení. Vyřazení agenta se dokončí až po nahlášeném úspěchu; nahlášené selhání nechá agenta aktivního (uninstall_status = failed) pro opakování a chybějící report je zobrazen jako čekající na potvrzení. Nepodporovaná rozložení (nebalíčkové/ruční instalace, macOS, offline) vrátí jasný fallback na odregistraci s ručním odstraněním. Deployment (bootstrap) záznamy získaly soft-delete životní cyklus — DELETE /api/v1/deployments/:id (chráněno deployment:write, scoped na organizaci) zneplatní enrollment token a instalační script bez dopadu na již registrované agenty a veřejné script/config endpointy pak vrací 404. Odpovědi list deploymentů používají dedikované DTO DeploymentResponse bez tokenu s vypočteným příznakem usable, zatímco odpověď create vrací bootstrap token právě jednou přes DeploymentCreatedResponse (závisí na něm UI, Go SDK i Terraform provider). Záložka Nasazení → Agenti se stává operační konzolí (odregistrace s náhledem dopadu a důvodem, vzdálená odinstalace, přeregistrace s jednorázovým tokenem, viditelné chybové stavy) a Nasazení → Nasadit získává akce smazat, zobrazit script a fallback kopírování. Nakonec go test sada modulu agenta nyní běží v PR, dev i release CI (dříve pouze cross-kompilace) a test invalidace filesystem-discovery politiky, který byl citlivý na běh pod rootem, byl zdeterminován.
Rotační šablony získávají políčka politiky a režim úschovy tajemství — Šablony konfigurace rotace nyní nesou lead_time_days (dní před expirací pro zahájení obnovy certifikátu), grace_period_days (dní, po které zůstává předchozí hodnota platná pro rollback) a secret_custody_mode (local, transient nebo delegated). Tato pole jsou vystavena přes API rotačních šablon, Go SDK i Terraform resource mazevault_rotation_template a jsou end-to-end sladěna s perzistovaným katalogem (migrace 000195). Schéma API rotačních šablon a jeho dokumentace Swagger byly aktualizovány, aby nová pole popisovaly. Šablona navíc vystavuje project_id (volitelné omezení na projekt) a retry_delay_seconds a na Terraform resource je organization_id nyní Optional+Computed (rozřešeno serverem) s jednou sdílenou flatten cestou, takže create, read a update se nemohou rozejít; tyto přírůstky mapují již perzistované sloupce a nevyžadují novou migraci.
Objevené certifikáty: vyhledávání a režimy přiřazení — Stránka Objevené certifikáty přidává serverový filtr search a explicitní režimy přiřazení pro adopci objevených certifikátů do správy, včetně endpointu hromadné adopce (POST /discovered-certificates/bulk/adopt, chráněno discovered_cert:bulk) vedle single-item cesty adopce. Samostatná routa Certificate Discovery byla odstraněna a nyní přesměrovává na Objevené certifikáty.
Akční stav rotace na Dashboardu — Dashboard nyní pomocí nového navigačního resolveru rozřeší rotační položky na jejich akční cíl, takže záznamy stavu rotace odkazují přímo na plochu, kde s nimi lze pracovat.
Nasazení sloučeno pod Enterprise Functions (chráněno PoC / Enterprise) — Configuration Management, SSH Management, KeyTab Management a Deployment nyní sídlí společně se Správou tokenů pod jednou navigační skupinou Enterprise Functions, která je čistě seskupovací hlavičkou — pouze se rozbaluje/sbaluje a sama nikam nenaviguje. Configuration, SSH a KeyTab už byly chráněny svými license featurami config_management / ssh_management / keytab_management; Deployment je nyní chráněn stejně novou featurou deployment_management udělovanou licencím PoC a Enterprise (stav active, grace nebo expiring). Skupina správy /api/v1/deployments (create / list / delete) je vynucena na straně serveru přes FeatureLicenseMiddleware a pro Small Business či nelicencované tenanty vrací HTTP 403; stránka Deployment místo záložek zobrazí upgrade banner. Uživatelé položku v menu stále vidí, pokud drží odpovídající RBAC oprávnění. Neautentizované, UUID-chráněné bootstrap endpointy agenta (/deployments/:id/script, /config, /agent-binary) zůstávají záměrně nechráněné, aby bezobslužné instalace agentů dál fungovaly, a endpointy správy agentů/gateway se nemění.
PDF zprávy o souladu se generuje na serveru — Nový GET /api/v1/compliance/{type}/pdf (oprávnění audit:read; typy pci-dss, soc2, gdpr, iso27001, starší pci a sox) vrací zprávu o souladu jako PDF přílohu (compliance-report-<framework>-<čas UTC>.pdf) se stejným obsahem a pořadím jako dřívější export v prohlížeči: souhrn se skóre, rozpis kontrol, statistiky certifikátů a rotací, politika hesel, doporučení a čísla stránek. Časy jsou v UTC a vložené písmo Inter správně zobrazí diakritiku. PDF vzniká při stažení, proto jeho čas „Generated“ odpovídá času stažení.
Filtr integrací organizace podle kategorie — GET /api/v1/organizations/{id}/integrations přijímá volitelný parametr dotazu category (notification, log_stream, archive; přesná shoda) a pak vypíše jen integrace této kategorie. Bez něj je odpověď beze změny.
Audit nastavení reportu, spuštění reportu a změn kontaktů pro incidenty — PUT /api/v1/reports/settings, POST /api/v1/reports/trigger a PUT /api/v1/organization/incident-contacts nyní zaznamenávají UPDATE_REPORT_SETTINGS (entita REPORT_SETTINGS, detail <n> recipients), TRIGGER_WEEKLY_REPORT (entita WEEKLY_REPORT) a UPDATE_INCIDENT_CONTACTS (entita ORGANIZATION, id organizace, detail <n> contacts) s jednajícím uživatelem a IP. Záznamy nikdy neobsahují e-mailové adresy.
Audit změn governance reportů — POST /api/v1/governance/reports, POST /api/v1/governance/reports/{id}/analyze a DELETE /api/v1/governance/reports/{id} nyní zaznamenávají UPLOAD_GOVERNANCE_REPORT (detail source_type=<typ>, <n> bytes), ANALYZE_GOVERNANCE_DRIFT (detail overall_score=<skóre>) a DELETE_GOVERNANCE_REPORT (entita GOVERNANCE_REPORT, id reportu) s jednajícím uživatelem a IP. Záznamy nikdy neobsahují obsah reportu ani jeho název; odmítnuté volání (neznámý report) záznam nezanechá.
Limit seznamu rotací vyžadujících pozornost — GET /api/v1/dashboard/rotation/actionable přijímá volitelný parametr limit (celé číslo alespoň 1), který ponechá jen první řádky seznamu; jiná hodnota vrací 400 Invalid limit. Bez něj se odpověď nemění.

Vylepšení¶

Seznam integrací filtruje podle stavu zapnutí — GET /api/v1/integrations přijímá volitelný parametr enabled (true: jen zapnuté integrace, false: jen vypnuté); jiná hodnota vrací 400 invalid enabled. Bez něj se seznam nemění. Dashboard Entra jej používá místo filtrování na klientovi.
Stránkování auditního logu na serveru — Stránka auditního logu v konzoli nyní načítá vždy jednu stránku po 100 záznamech přes stávající limit, offset a total endpointu POST /api/v1/audit-logs/search a zobrazuje celkový počet s navigací mezi stránkami; dřívější stránka načetla jednu pevnou stránku 100 záznamů a ke starším se nedostala. Filtry a stránka se drží v URL. API se nemění.
Doplnění privátního klíče k existujícímu certifikátu (vydanému z CSR nebo importovanému bez klíče) — Certifikáty podepsané z nahraného CSR jsou uloženy s custody klíče none; operátor nyní může klíč MazeVaultu dodat dodatečně z Detail certifikátu → Overview → Import private key (PEM klíč, šifrovaný PEM klíč, PFX/P12 nebo vložený PEM) s lokální nebo secret-manager custody při respektování Orchestrator Mode. Nebyl zaveden žádný nový endpoint: dialog využívá POST /certificates/import/file a nový volitelný parametr expected_certificate_id (dostupný i na POST /certificates/import) přiváže požadavek k jedinému certifikátu, takže cizí materiál je odmítnut místo vytvoření či změny jiného záznamu. Import více souborů nyní páruje samostatné .key soubory s certifikátem přes backendové párování preview-multi (nové pole key_source_file v odpovědi náhledu) a odesílá certifikát s klíčem v jednom požadavku, takže zvlášť nahraný klíč dorazí k již spravovanému certifikátu. Vyhledání duplicity/cíle je nyní primárně podle SHA-256 otisku (serial + issuer zůstává jako legacy fallback, který odmítne řádky s odlišným uloženým otiskem), kontrola custody respektuje externí úložiště (externě uložený klíč není nikdy tiše nahrazen lokální kopií), import v rámci projektu už nemůže změnit certifikát patřící jinému projektu, doplnění klíče nikdy nemění nastavení obnovy certifikátu ani nedegraduje bohatší uložený řetězec a chyba „already exists“ nyní vysvětluje, jak klíč doplnit.
Nahraná CSR se validují vůči šabloně před kontaktováním CA — Nahraná CSR nyní selžou okamžitě při odeslání, pokud porušují explicitní politiku šablony: vlastní podpis musí být platný, velikost klíče musí být v allowed_key_sizes, je-li nastaveno (dříve vynucováno jen interní CA, nikdy ADCS ani externími CA), a SAN položky musí vyhovět explicitní san_config (allowed_san_types, san_validation_pattern, max_san_count a nový příznak require_san, který odmítne CSR pouze s CN). Výchozí chování je záměrně permisivní — šablony bez san_config přijímají každé CSR jako dosud — a systémové šablony (mTLS agentů/gateway) jsou vyjmuty. Požadované SAN a parametry klíče nahraného CSR se nyní zaznamenávají na požadavku pro auditovatelnost.
Požadavky vyžadující schválení správcem ADCS se sledují místo selhání — Vydání nového certifikátu přes ADCS CA vyžadující manager approval už nevrací HTTP 500, zatímco CA drží enrollment: požadavek přejde do submitted_to_ca a po schválení v CA jej automaticky dokončí poller externích objednávek. CA providery mohou implementovat nové volitelné rozhraní IssuedCertificateFetcher vracející vydaný leaf podle ID objednávky; ADCS jej implementuje, čímž je opraven latentní defekt, kdy by poller uložil CA řetězec jako leaf.
Životní cyklus požadavku po selhání vydání — Automaticky schválený požadavek, jehož vydání selže, je nyní označen failed se zaznamenanou chybou (místo setrvání v approved bez certifikátu) a ručně schválený požadavek se při selhání vrátí do pending, aby jej schvalovatel mohl zopakovat; pozdější úspěšné vydání zaznamenanou chybu vymaže. Enum stavu požadavku dokumentuje stav failed a UI jej zobrazuje.
Kanonické kódování sériového čísla certifikátu — certificates.serial_number se konzistentně ukládá jako decimální řetězec big-integeru, který už používají OCSP, revokace a import. Vydání přes ACME a HashiCorp Vault, finalizace externích objednávek a rychlá cesta vestavěného ACME serveru dříve zapisovaly či dotazovaly hexadecimální serialy, což u těchto certifikátů rozbíjelo deduplikaci importu a indexované vyhledávání ACME serveru. Revokace a dotazy stavu ve Vaultu překládají kanonický serial zpět do Vaultem očekávaného colon-hex formátu, takže fungují legacy i normalizované řádky. Idempotentní backfill identity (BackfillCertificateIdentity) znovu odvodí serial a otisky z uloženého DER; běží na pozadí při startu primary a je součástí POST /admin/certificates/backfill, který nyní vrací identity_normalized.
Editor šablon už nepřepíná „Allow Additional SANs“ — allow_additional_sans v API pro vytvoření/úpravu šablony certifikátu nyní rozlišuje přítomnost (vynechané zachová uloženou hodnotu; explicitní false je respektováno). Dříve update bez tohoto pole — které editor šablon nikdy neposílá — hodnotu resetoval na false.
Rozřešení scope integračních skupin pro RBAC — Nový IntegrationGroupScopeMiddleware rozřeší samostatné ID integrační skupiny na její vlastnící aktivní projekt ještě před vyhodnocením projektového RBAC a odmítne požadavky na skupiny, jejichž projekt je archivovaný nebo chybí. Díky tomu lze endpointy integračních skupin autorizovat konzistentně se zbytkem projektového RBAC modelu.
Životní cyklus revokace SSH authorized-key — Agenti mohou dotazovat čekající revokace authorized-key (GET /agent/authorized-keys/pending-revocations) a potvrdit jejich dokončení (POST /agent/authorized-keys/:id/confirm-revocation) a operátoři mohou authorized-key revokovat (POST .../authorized-keys/:id/revoke) i opakovat selhané nasazení SSH klíče (PUT /ssh-keys/:id/deploy). Zastavenou nebo částečně selhanou exekuci rotace lze obnovit přes POST /rotation/executions/:id/resume. Potvrzovací zpráva u rotace SSH klíče byla rovněž zpřesněna.
Runtime cíle rotace směrují jen přes aktivní agenty — Když rotace deleguje práci na agenta (například nasazení keytab nebo SSH), runtime nyní rozřeší navázaného agenta a odmítne směrovat přes agenta, který je neaktivní, revokovaný nebo soft-smazaný, a vrátí jasnou chybu místo proxování na mrtvý cíl.
Validace číselných polí rotačních šablon — Číselná pole rotačních šablon (rotation_interval_days, lead_time_days, grace_period_days, max_retry_attempts, retry_delay_seconds, timeout_minutes) jsou nyní validována jako nezáporná celá čísla napříč backend API, frontendem i Terraform providerem, se strukturovanými aplikačními chybami místo nesrozumitelných selhání. Pole retry_delay_seconds — již perzistované a vystavené přes API, SDK i Terraform resource — je nyní editovatelné i ve formuláři rotační šablony v UI, takže jej lze nastavit a zobrazit z konzole. Hromadná adopce certifikátů zobrazuje uživatelsky přívětivé zprávy pro částečná selhání.
Elegantní vypnutí backendu při SIGTERM — API server nyní při obdržení SIGTERM vyprázdní probíhající požadavky přes http.Server.Shutdown — s lhůtou pro vyprázdnění drženou pod terminační grace period Kubernetes — a poté před ukončením zastaví služby log-stream a audit-archive na pozadí, místo aby byl při rolloutech tvrdě zabit uprostřed požadavku. http.ErrServerClosed je považován za normální ukončení.
Vynucení vlastnictví SSH authorized-key — Výpis, nasazení, revokace a odstranění SSH authorized-key (a výpis párů klíčů) nyní konzistentně vynucují vlastnictví páru klíčů — jednající uživatel musí pár klíčů vlastnit nebo mít ssh:admin — v souladu s kontrolami vlastnictví již uplatňovanými u get, export a delete. Neadmin už nemůže vypsat inventář klíčů jiného uživatele ani nasazovat/revokovat/odstraňovat klíče, které nevlastní; producentská revokace a odstranění plus agentní potvrzení revokace nyní zapisují auditní záznamy s kontextem request-ID.
Obnova rotace vyžaduje autentizovaného aktéra — POST /rotation/executions/:id/resume nyní odmítne požadavek bez autentizovaného principalu s HTTP 401 ještě před během orchestrátoru a zaznamenává úspěšné i neúspěšné obnovy s plným auditním kontextem request-ID.
Stabilita recovery tokenu agenta (bez zamčení při re-registraci) — Re-registrace agenta již při každém volání nerotuje stále platný recovery token. Nový recovery token se razí pouze tehdy, když se agent bootstrapuje/přeinstaluje deployment tokenem nebo nemá použitelný token v evidenci; agent, který se autentizuje svým aktuálním recovery tokenem, si jej ponechává. Ve spojení s atomickou, pádu-odolnou perzistencí stavu agenta — zrotovaný token i identita se připraví a do paměti potvrdí až po úspěšném durabilním zápisu a nahrazení dočasného souboru je nyní atomické i na Windows (MoveFileEx s nahrazením existujícího), nejen na POSIX — už agent, který spadne nebo neuloží zrotovaný token, nemůže být trvale zamčen. Jde pouze o behaviorální zpevnění — žádná změna schématu ani API kontraktu.
Seznam projektů a souhrn archivu přijímají volitelné filtry — GET /api/v1/projects/ přijímá volitelné parametry dotazu search (název projektu obsahuje text, bez ohledu na velikost písmen) a type (secret, key nebo certificate, přesná shoda). GET /api/v1/archived/summary přijímá volitelné archived_from a archived_to (RFC 3339, včetně krajních hodnot, podle archived_at) a expiring_within_days (celé číslo alespoň 0, ponechá položky, jejichž days_until_deletion je nejvýše tato hodnota); filtrují archivované projekty, tajemství a certifikáty, nikdy ne uživatele, a total_count počítá vypsané položky. Neplatná hodnota vrací 400. Bez parametrů jsou obě odpovědi beze změny a konzole je nově posílá místo filtrování v prohlížeči.
Porovnání secretů podle klíče na backendu — POST /api/v2/secrets/compare přijímá volitelný query parametr by: blind_index (výchozí, beze změny) nebo key, který porovná secrety s klíčem (starší, legacy) obou prostředí podle klíče a vrátí každý výsledek s polem key (blind_index zůstává prázdný), seřazené podle klíče. Jiná hodnota vrací 400. Záložka Secrets toto porovnání dosud prováděla v prohlížeči.
Seznamy certifikátů filtrují, řadí a stránkují na backendu — GET /api/v1/certificates/ přijímá volitelné parametry dotazu search (běžné jméno, primární DNS jméno, DN vydavatele nebo subjektu, název projektu, sériové číslo, DNS jméno ze SAN nebo štítek obsahuje text, bez ohledu na velikost písmen), status a type (přesná shoda), expiring_within_days (celé číslo alespoň 0, ponechá aktivní certifikáty, kterým vyprší platnost nejpozději za tolik dnů), sort (common_name, primary_dns_name, issuer, expiry_date, days_until_expiry, san_count nebo project_name) s order (asc, výchozí, nebo desc) a limit (nejvýše 500) s offset. GET /api/v1/projects/{id}/certificates přijímá search, status (efektivní stav včetně rolling out a deployment failed), type, environment, tag, sort (common_name, serial_number, certificate_type, expiry_date nebo status), order, limit a offset; environment je zároveň prostředí, ve kterém se požadavek posuzuje. Filtry se použijí na certifikáty, které smí uživatel číst, stejné řádky se řadí podle id, aby se hranice stránky nepřesouvala, a hlavička X-Total-Count nese počet řádků, které filtry ponechají. Neplatná hodnota vrací 400. Nové GET /api/v1/certificates/analytics vrací agregaci pro dashboard (součty podle stavu, brzy expirující, podle typu a algoritmu klíče, 8 nejčastějších vydavatelů a projektů, časová osa expirací na dalších 6 měsíců UTC) pro stejné certifikáty. Bez parametrů jsou seznamy beze změny a konzole je nově posílá místo filtrování a počítání v prohlížeči.
Potvrzení před akcemi s přihlašovacími údaji, nasazením a rotací — Webové rozhraní se nyní zeptá, než zobrazí uloženou hodnotu spravovaného tokenu, exportuje soukromý klíč SSH, stáhne keytab, nasadí nebo odebere autorizovaný klíč SSH, podepíše klíč SSH, okamžitě synchronizuje cíl nasazení tajemství nebo certifikátu, obnoví běh rotace, vytvoří identitu služby (její klientské tajemství se zobrazí jen jednou) a smaže šablonu rotace nebo keytab. Každé spuštění rotace, rotace systémového klíče (potvrzuje se zadáním účelu klíče) a dosavadní potvrzení smazání, obnovení a odpojení si ponechávají své znění. Zkušební běhy (dry run) jsou jen pro čtení a nepotvrzují se; vytvoření tokenu, import keytabu nebo klíče SSH a uložení konfigurace či šablony rotace zůstávají běžným odesláním formuláře.
Kontrola oprávnění stránek SSH, keytabů, tokenů a identit služeb — Stránky SSH Management, KeyTab Management, Token Management a Service Identities neměly vlastní kontrolu oprávnění, takže uživatel bez přístupu dostal hlášení 403 u každého požadavku stránky. Nyní zobrazí stránku s odepřeným přístupem, pokud uživatel nemá oprávnění jejich položky v postranním panelu (ssh:read, keytab:read, token:read, service_identity:read); Rotation Templates vyžaduje rotation:read a Rotation Problems dashboard:read. Bez licenční funkce zobrazí stránky SSH, keytabů a tokenů upozornění na upgrade a nic nenačítají.
Vyhledávání uživatelů na backendu — GET /api/v1/rbac/users přijímá volitelný parametr dotazu search: uživatel odpovídá, když je oříznutý text obsažen v celém jméně nebo e-mailu bez ohledu na velikost písmen; prázdné hledání nic nemění a bez shody je odpovědí []. Dialog přiřazení klíče SSH hledá jeho pomocí, místo aby filtroval celý adresář uživatelů v prohlížeči.
Správa konfigurací: odstraněna nefunkční tlačítka — Nová konzole už nezobrazuje tlačítka Preview a Adopt v Configuration Management → Discovered Configurations ani Restore to Pending ve Staging Area: nic nedělala. Ignorovat (vyžaduje config:write, ptá se na potvrzení) zůstává beze změny a Staging Area nemá sloupec Akce.
Fakturace: odstraněny ukazatele využití — Panel Usage Limits na stránce /billing zobrazoval ukazatele vyplněné pevně na 50 % a 20 %, které neodpovídaly žádnému skutečnému využití. Nová konzole zobrazuje u projektů a tajemství jen limity (Unlimited nebo Limit: N).
Fakturace: Renew License a Activate vyžadují billing:write — /billing vyžaduje billing:read, ale tlačítko Renew License a formulář Update License (Activate) zobrazoval každému, kdo stránku otevřel; obnovení i aktivace vyžadují billing:write, takže kliknutí uživatele jen pro čtení skončilo 403. Obojí se nyní zobrazí jen s billing:write; údaje licence, limity využití a upozornění na omezený režim zůstávají viditelné s billing:read.
Konzole: méně zbytečných požadavků, neúspěšná čtení jako chyby — Dialog gatewaye Assign Environments ukazoval neúspěšné čtení prostředí (například bez env:read) jako „No environments found“; nyní ukáže chybu s Retry. Úprava a obnovení licence se po chybě serveru nebo ztrátě spojení už neposílají znovu (každé volání se audituje). Projekt certifikátů nebo klíčů už nečte integrace projektu (záložku Entra Apps mohou mít jen projekty tajemství) a seznamy projektů v konzoli se čtou jen s project:read v některém projektu, místo aby vracely 403.
Upozornění na aktualizaci pro uživatele s system:read — Nová konzole zobrazí upozornění, když je k dispozici novější verze MazeVault (Update Available, u kritické verze Critical Update Available), s aktuální a nejnovější verzí, začátkem poznámek k vydání a odkazem ke stažení. Zobrazí se a stav aktualizace se načítá jen uživatelům s oprávněním system:read, které vyžadují routy aktualizací. Zavření ho skryje na dobu relace záložky prohlížeče; Re-check se znovu zeptá aktualizačního serveru a při selhání zobrazí chybovou zprávu.
Potvrzení před akcemi nasazení, gateway a Entra — Webové rozhraní se nyní zeptá také předtím, než vygeneruje nasazení (vytvoří bootstrap token), znovu zaregistruje agenta (náhradní token), vyžádá vzdálenou odinstalaci agenta, uloží politiku verzí agentů (platí pro všechny nasazené agenty), uloží přiřazení prostředí gateway (podle něj se směrují úlohy gateway), přidá přihlašovací údaj k aplikaci Entra (vytvoří tajemství v Entra ID), synchronizuje integraci Entra (Sync from Entra přepíše uložené aplikace a přihlašovací údaje) a použije nahraný systémový certifikát. Smazání přihlašovacího údaje Entra si ponechává své znění; odregistrování agenta si ponechává svůj dialog s důvodem a dopadem a změna aktualizačního kanálu jednoho agenta se nepotvrzuje.

Opravy chyb¶

Linuxový agent neběžel na hardened hostitelích ani na RHEL 8 — Linuxového agenta na zákaznických hostitelích zastavovaly dvě nezávislé chyby. (1) Binárka agenta v release byla sestavená se zapnutým cgo, byla tedy dynamicky linkovaná proti glibc sestavovacího stroje a na RHEL/Rocky/AlmaLinux 8 selhala s /lib64/libc.so.6: version `GLIBC_2.34' not found; agent se nyní sestavuje s CGO_ENABLED=0 -trimpath, je linkován staticky a běží s libovolnou verzí glibc. (2) Nasazovací instalační skript ukládal binárku do /var/lib/mazevault/bin; na hostitelích s /var připojeným noexec (CIS/STIG baseline) systemd selhal se status=203/EXEC v nekonečné restartovací smyčce. Instalátor i balíček rpm/deb nyní instalují binárku do /opt/mazevault-agent/bin (vlastník uživatel agenta, adresář v ReadWritePaths, aby dál fungoval self-update, SELinux bin_t). Instalátor byl přepracován pro hardened hostitele: set -euo pipefail, preflight (kontrola noexec adresáře binárky přes findmnt, detekce SELinuxu, potřebné nástroje), už žádný fallback curl -k (s CA MazeVault ji stažení použije a při neúspěchu přejde na systémové úložiště důvěryhodných certifikátů, nikdy na nezabezpečený režim), při neúspěšném stažení se vypíše HTTP stav a tělo chybové odpovědi serveru (např. 503 agent binary downloads not configured), selhání curl po HTTP 200 (useknutý přenos) se počítá jako neúspěšné stažení a podepsaná binárka se připraví jako mazevault-agent.new a spustí jako mazevault-agent (version) dříve, než nahradí nainstalovanou binárku a než se zapíše unita, takže noexec připojení, zamítnutí SELinuxem nebo nesoulad glibc instalátor zastaví se srozumitelnou hláškou, dříve nainstalovaného agenta nechá nedotčeného a nikdy nezpůsobí restartovací smyčku, agent.yaml se zapisuje s právy 0640, používá se systemctl restart, aby opakované spuštění aktualizovalo běžícího agenta, hostitelé instalovaní s předchozím rozložením se migrují (stará binárka odstraněna, drop-in přepisy ExecStart odstraněny, ostatní drop-iny zachovány) a návratové kódy jsou 2 preflight / 3 stažení či ověření / 4 služba neběží (stav a journal se vypisují s redigovanými tokeny a UUID). Pokud server nemá nakonfigurovanou CA, instalátor už nezapisuje prázdný ca.crt a vygenerovaný agent.yaml nechává server_ca_file prázdné, takže agent ověřuje server systémovým úložištěm důvěryhodných certifikátů; instalátor pro Windows obdobně prázdnou CA nezapisuje ani neimportuje. Self-update agenta a runner vzdálené odinstalace nyní volí adresář, který je zapisovatelný a není na noexec připojení (adresář binárky, stavový adresář, poté dočasný adresář), místo předpokladu, že /tmp umožňuje spouštění, a pokud žádný nevyhovuje, vypíší odmítnuté adresáře. Vzdálená odinstalace rozpozná hostitele instalované skriptem (bez balíčku rpm/deb): unita, drop-iny a adresáře agenta se odstraní přímo místo selhávajícího rpm -e a zastavení služby, odstranění unity a odstranění /opt/mazevault-agent jsou povinné kroky, jejichž selhání se serveru nahlásí místo falešného úspěchu, /opt/mazevault-agent se odstraní jen tehdy, když v něm binárka skutečně je, a požadavek na roota je vysvětlen v chybové hlášce. Nová volitelná proměnná MAZEVAULT_CA_FILE (release kit, instalátory, check-config.sh, hodnoty Helm, dokumentace) určuje CA vkládanou do instalačních skriptů; Compose kit pro ni připojuje CUSTOM_CERT_DIR do backendu jako /custom-certs. Operátoři, kteří 203/EXEC obešli drop-inem ukazujícím na /usr/local/bin, pouze znovu spustí instalační skript.
Výpadek backendu už uživatele neodhlásí — Když kontrola relace webového rozhraní selže chybou serveru, brány nebo sítě, rozhraní nyní uživatele ponechá přihlášeného a trezor odemčený (backend, který neodpoví do 15 sekund, se počítá jako taková chyba); při prvním načtení zobrazí „MazeVault is not reachable. Try again in a moment.“ a „Back to home“ kontrolu zopakuje. Na přihlašovací stránku vede jen vypršelá nebo chybějící relace (HTTP 401). Odmítnuté volání kontroly na pozadí (například stavu šifrování po přihlášení) zobrazí jen svou jednu zprávu místo dvou.
Zpráva o chybném starém hesle už neobsahuje interní text — Změna hesla se špatným současným heslem (POST /api/v1/auth/password) stále vrací HTTP 400, ale zpráva je nyní jen UNAUTHORIZED: invalid old password; interní text porovnání hash hesla se už v odpovědi neobjevuje.
Připravený sekundární údaj Entra se vytvoří jen jednou — Dvě souběžná volání POST /api/v1/entra/credentials/{id}/staged-secondary (dvojklik, klient s opakováním nebo volání pro dva přihlašovací údaje téže aplikace) prošla kontrolou „jeden připravený sekundární údaj na aplikaci“ a každé vytvořilo v Entra živé klientské tajemství a čekající sekundární údaj. Aplikace má nyní najednou jen jeden připravený cyklus: volání zabere svůj údaj, zatímco je aplikace zamčená, dřív než požádá Microsoft Graph (nebo bránu) o tajemství, a vrátí 409 bez zásahu do Entra, pokud jiný údaj aplikace právě rotuje nebo čeká připravený sekundární údaj (a staged secondary credential is already in progress for this application; …, a credential of this application is rotating; …). Připravený sekundární údaj ani vyřazovaný bývalý primární údaj nemůže spustit připravený cyklus (409) a údaj, jehož běžná rotace čeká na ověření (stav pending_verification), se počítá jako rotující. Smazání aplikace počká na probíhající zabrání, místo aby selhalo na zablokování databáze. Zabrání se uvolní na konci volání, i když selže; pokud se server uprostřed volání zastaví, uvolní ho po 30 minutách hlídač zaseknutých rotací.
Změny přihlašovacích údajů Entra se auditují — Smazání přihlašovacího údaje Entra (DELETE /api/v1/entra/credentials/{id}) nezanechalo záznam auditu, uložení jeho konfigurace rotace (POST …/rotation-config) jen záznam bez uživatele a suchý běh PUT …/rotation-config žádný. Nyní zaznamenávají DELETE_ENTRA_CREDENTIAL, ENTRA_ROTATION_CONFIGURED (se zapnutím, dny předstihu a odkladu a počtem akcí po rotaci) a ENTRA_DRY_RUN_PREFLIGHT s uživatelem, až když změna uspěje, jeden záznam na uložení (dodatečný záznam bez uživatele, entra.rotation.configured / entra.rotation.disabled, se už nezapisuje); odmítnuté volání nezaznamená nic.
Aktivace gatewaye, přiřazení prostředí, DR failover a bootstrap tokeny se auditují — Aktivace a deaktivace gatewaye, přiřazení jejích prostředí, aktivace DR a failback a vydání bootstrap tokenu gatewaye nebo agenta nezanechávaly záznam auditu. Nyní zapisují ACTIVATE_GATEWAY / DEACTIVATE_GATEWAY a UPDATE_GATEWAY_ENVIRONMENTS (entita GATEWAY, id gatewaye; prostředí a jejich režimy), ACTIVATE_GATEWAY_DR / FAILBACK_GATEWAY_DR (entita ENVIRONMENT, prostředí), CREATE_GATEWAY_BOOTSTRAP (entita GATEWAY, id nové gatewaye a její název) a CREATE_AGENT_BOOTSTRAP_TOKEN (entita DEPLOYMENT) s uživatelem a IP adresou. Žádný záznam neobsahuje token; odmítnuté volání nezapisuje nic.
Připravený sekundární údaj Entra se ověří a povýší jen jednou — Souběžná volání POST /api/v1/entra/credentials/{id}/verify-secondary nebo POST …/promote-primary (dvojklik, klient s opakováním) mohla uspět všechna: sekundární údaj se povýšil dvakrát a jeho dřívější primární údaj se dvakrát snížil, s počtem rotací zvýšeným za každé volání. Přechod nyní nejprve zabere údaj v jeho aktuální fázi: jedno volání uspěje, ostatní vrátí 409 a nic nezmění.
Trasy přihlašovacích údajů Entra už nevracejí interní text chyby — POST /api/v1/entra/credentials/{id}/staged-secondary a POST …/promote-primary odpovídaly na každé selhání 409 s jeho textem, včetně selhání Microsoft Graph nebo databáze a konfigurace, kterou nešlo dešifrovat (credential not found: decryption failed: …); PUT …/rotation-config, POST …/dry-run a GET /api/v1/entra/subjects/{id} vkládaly interní text chyby do své odpovědi 500. Odmítnutý přechod stavu dál vrací 409 se zprávou (připravený sekundární údaj už probíhá, údaj je primární, není způsobilý nebo ještě neuplynulo jeho ověřovací okno); jakékoli jiné selhání nyní vrací 500 {"error": "Internal server error"} a příčina je v logu serveru.
Zkušební běh Entra neukazuje interní text chyby — Neúspěšná kontrola zkušebního běhu přihlašovacího údaje Entra (POST /api/v1/entra/credentials/{id}/dry-run, PUT …/rotation-config s dry_run) nesla v checks a v uloženém dry_run_last_result interní chybu, například chybu dešifrování konfigurace integrace. Neúspěšná kontrola nyní nese pevný důvod (credential not found or not readable, app registration not accessible, integration not found, integration configuration is invalid, cannot connect to Entra ID); příčina se zapíše do logu serveru.
Uložení konfigurace rotace Entra jako zkušební běh nic neuloží — POST /api/v1/entra/credentials/{id}/rotation-config (dialog Configure Rotation) ignoroval dry_run a konfiguraci uložil, přestože Dry Run Mode dialogu slibuje jen kontroly preflight. Stejně jako PUT nyní vrací {"dry_run": true, "preflight": {…}} s preflightem jen pro čtení, nic neuloží a zapíše ENTRA_DRY_RUN_PREFLIGHT. API klient, který posílal dry_run: true a spoléhal na uložení, musí příznak vynechat.
Dialog rotace Entra ukazuje výsledek zkušebního běhu — Se zapnutým Dry Run Mode se dialog Configure Rotation přihlašovacího údaje Entra zavřel, jako by konfiguraci uložil. Jeho tlačítko nyní zní Run Dry Run; dialog zůstane otevřený, ukáže výsledek preflightu (stav, zprávu a každou kontrolu) a nic neuloží. Přepínač platí jen se zapnutou automatickou rotací, kde se zobrazuje.
Úprava konfigurace rotace Entra zachová akce po rotaci, které posílá — PUT /api/v1/entra/credentials/{id}/rotation-config (používá ho mazevault_entra_rotation_config providera Terraform při každé úpravě) ignoroval post_rotation_actions v těle: nahradil je akcemi odvozenými ze starších polí, a jakmile byly nastavené pokročilé akce, odmítal každou úpravu. Poslané akce se nyní uloží (prázdný seznam je smaže); bez tohoto pole platí starší pole jako dosud.
Neplatná nastavení rotace Entra vracejí 400 — POST /api/v1/entra/credentials/{id}/rotation-config (dialog rotace Entra) odpovídal na neplatnou akci po rotaci (nepodporovaný typ, chybějící pole, nepodporované on_failure) a na zapnutou rotaci bez post_rotation_actions, když jsou nastavené pokročilé akce, 500 internal error a PUT …/rotation-config (provider Terraform) odpovídal na tyto případy a na soak_window_hours menší než 1 500 se zprávou. Nyní vracejí 400 se zprávou (například post_rotation_actions[0]: unsupported Entra post-rotation action type "ftp_upload"); nic se neuloží.
Změny aplikací Entra se auditují — Vytvoření, úprava a smazání registrace aplikace Entra, přidání přihlašovacího údaje, označení aplikace jako spravované MazeVaultem a synchronizace aplikací integrace z Entra měnily MazeVault i Entra bez záznamu v auditu. Nyní po změně zapisují CREATE_ENTRA_APP, UPDATE_ENTRA_APP (změněná pole), DELETE_ENTRA_APP, ADD_ENTRA_CREDENTIAL (typ a zobrazovaný název; nikdy tajemství), MARK_ENTRA_APP_MANAGED a SYNC_ENTRA_APPS; odmítnuté nebo neúspěšné volání a označení aplikace, která už spravovaná je, nic nezapisuje.
Přidání certifikátu k aplikaci Entra vrací 400 — POST /api/v1/entra/apps/{id}/credentials (dialog Add Credential aplikace Entra, který nabízí Certificate) odpovídalo na credential_type jiný než client_secret kódem 500 internal error, protože tam lze vytvořit jen tajný klíč klienta. Nyní vrací 400 unsupported credential type "certificate": only client_secret credentials can be added dřív, než se cokoli načte nebo odešle do Entra.
Čtení aplikace Entra už nevrací interní text chyby — GET /api/v1/entra/apps/{id} odpovídalo na každé selhání 404 s textem chyby, i na selhání databáze nebo konfiguraci integrace, kterou nešlo dešifrovat (decryption failed: …), a GET /api/v1/entra/{integrationId}/subjects vkládalo text databáze do své odpovědi 500. Chybějící aplikace dál vrací 404 record not found; jakékoli jiné selhání nyní vrací 500 bez interního textu (čtení {"code": "INTERNAL_ERROR", "message": "internal error"}, subjekty {"error": "Internal server error"}) a příčina je v logu serveru.
Interval synchronizace kratší než jedna minuta se uloží jako jedna minuta — V Nastavení projektů → Nastavení synchronizace i v Nastavení projektu → Konfigurace synchronizace se interval kratší než 1 minuta (například záporné číslo) ukládal tak, jak byl zadán. Nyní se uloží jako 1 minuta, v souladu s nápovědou „minimum 1 minute“. Prázdné pole nebo 0 se nadále nahradí 5 minutami.
Úprava výchozí šablony konfigurace zachová příznak Výchozí; odmítnuté uložení nechá průvodce otevřený — V Nastavení projektů → Šablony konfigurace uložení úpravy šablony označené jako výchozí už příznak výchozí nezruší (průvodce posílal is_default: false) a uložení, které backend odmítne, zobrazí jeho zprávu uvnitř průvodce místo jeho zavření.
Navrhnout pravidla v editoru politiky pojmenování tajemství skutečně přidá navržená pravidla — V Nastavení projektů → Šablony konfigurace tlačítko Navrhnout pravidla (Suggest Rules) v editoru politiky pojmenování tajemství četlo pole odpovědi, které backend nikdy neposílá (suggested_rules místo suggestions), a proto nikdy žádné pravidlo nepřidalo. Nyní přidá navržená pravidla, která politika ještě nemá, jako zapnutá varování, a při selhání požadavku zobrazí zprávu backendu. Pole Exact Values, Project Scope, Environment Scope a Subscription Scope v editoru politiky viditelnosti zdrojů přijímají při psaní čárku na konci, takže lze zadat druhou hodnotu.
Nesplněné podmínky failoveru vracejí 409, neplatné prostředí 400 — POST /api/v1/admin/failover/{environment}/activate-dr a …/failback vracely 500, když failover nešlo provést: chybí DR standby gateway, primární gateway je stále aktivní nebo primární gateway neexistuje. Tyto cesty jsou dokumentované API operátora pro DR a stav, který musí operátor nejdřív změnit, není chyba serveru. Nyní vracejí 409 se stejnou zprávou (například primary gateway … is still active for environment NPR; deactivate primary first to prevent split-brain), neplatné prostředí vrací 400 a selhání databáze 500 Internal server error.
Cesty gateway už nevracejí text interních chyb — Administrační cesty gateway (/api/v1/admin/gateways…, GET /api/v1/admin/failover/{environment}, GET /api/v1/admin/gateway-health), cesty úloh pro gateway (/api/v1/gateway/tasks…, GET /api/v1/gateways/{id}/tasks), podpis CSR gateway (POST /api/v1/gateways/csr, které vracelo Failed to submit CSR: …) a GET /api/v1/gateways/{id}/health vkládaly do odpovědi 500 text chyby služby nebo databáze. Nyní vracejí {"error": "Internal server error"} a příčina je v logu serveru.
Cesty agentů už nevracejí text interních chyb — Cesty životního cyklu agenta (GET /api/v1/agents/{id}/lifecycle-impact, POST /api/v1/agents/{id}/unregister, POST /api/v1/agents/{id}/reregister, POST /api/v1/agents/{id}/uninstall) a žádosti agenta o heslo (POST a GET /api/v1/agents/me/password-requests) vkládaly do odpovědi 500 text chyby služby nebo databáze, například agent has no organization; cannot issue a replacement token. Nyní vracejí {"error": "Internal server error"} a příčina je v logu serveru.
Ignorování a převzetí výsledku discovery konfigurací opět funguje — POST /api/v1/discovery-results/{id}/ignore (akce Ignorovat v Configuration Management → Discovered) a POST /api/v1/discovery-results/{id}/adopt vracely při každém volání 500 s prázdným tělem: handlery četly ID uživatele ve špatném tvaru. Nyní výsledek ignorují nebo převezmou, vracejí {"status": "ignored"} nebo nový konfigurační soubor a zapisují záznamy auditu IGNORE_CONFIG_DISCOVERY_RESULT a ADOPT_CONFIG_DISCOVERY_RESULT.
Neexistující konfigurační soubory a výsledky discovery vracejí 404, převzatý výsledek 409 — GET /api/v1/config-files/{id} a POST /api/v1/discovery-results/{id}/adopt vracely pro neexistující ID 500 Internal server error a POST /api/v1/discovery-results/{id}/ignore vracelo 200 {"status": "ignored"}, aniž by cokoli změnilo. Nyní vracejí 404 (configuration file not found, discovery result not found) a převzetí již převzatého výsledku vrací místo 500 odpověď 409 discovery result already adopted.
Cesty nasazení už nevracejí text interních chyb — POST, GET a DELETE /api/v1/deployments… a anonymní instalační cesty GET /api/v1/deployments/{id}/script a …/config vkládaly do odpovědi 500 text chyby služby nebo databáze (například no trusted agent signing keys: install scripts cannot verify the agent binary). Nyní vracejí {"error": "Internal server error"} a příčina je v logu serveru; odpovědi 400, 404, 410 a 422 se nemění.
Bezpečnost: převzetí výsledku discovery konfigurací se posuzuje v cílovém projektu — POST /api/v1/discovery-results/{id}/adopt vytvořilo konfigurační soubor v projektu project_id z těla požadavku a s extract_secrets do něj uložilo tajemství ze souboru, aniž by tento projekt ověřilo: kdokoli s config:write mohl zapisovat do libovolného projektu, i do projektu jiné organizace nebo neexistujícího. Volající nyní potřebuje config:write v tomto projektu (role omezená na projekt může převzít výsledek do něj, a jen do něj) a pro extrakci tajemství secret:write v prostředí dev projektu, kam se extrahovaná tajemství ukládají. Projekt, do kterého volající nesmí zapisovat, vrací 403; neexistující projekt nebo projekt jiné organizace vrací 404 Project not found.
Cesty pojmenovacích konvencí vracejí pro neznámou šablonu 404 a skrývají interní chyby — POST /api/v1/naming-conventions/{id}/render, …/parse, …/provision, …/terraform a …/cross-validate vracely 500 s textem chyby služby nebo databáze (například naming convention template not found: record not found). Neznámá šablona nyní vrací 404 {"error": "naming convention template not found"}, typ prostředku bez vzoru v šabloně nebo název prostředku bez kódu projektu 400 s touto zprávou a jakákoli jiná chyba {"error": "Internal server error"} s příčinou v logu serveru.
Seznamy synchronizačních událostí už nevracejí text interních chyb — GET /api/v1/sync/events (replikační peer) a GET /api/v1/sync-dashboard/events vkládaly do odpovědi 500 text chyby databáze. Nyní vracejí {"error": "Internal server error"} a příčina je v logu serveru.
Bezpečnost: pojmenovací konvence se posuzují ve své organizaci, šablony konfigurace neznámé organizace vracejí 404 — POST /api/v1/naming-conventions/{id}/render, …/parse, …/provision, …/terraform a …/cross-validate četly šablonu libovolné organizace a …/provision vytvořilo projekt v organizaci organization_id z těla požadavku, aniž by ji ověřilo: držitel config:read nebo config:write omezený na jednu organizaci mohl číst pojmenovací konvence jiné organizace a vytvářet projekty v jiné organizaci. Organizace šablony a při provisioningu i organizace z těla nyní vyžadují oprávnění v této organizaci (jinak 403); neznámá organizace v těle vrací 404 Organization not found. Cesty šablon konfigurace …/organizations/{id}/config-templates… nyní pro neznámou organizaci také vracejí 404 Organization not found (seznam vracel prázdný seznam).
Změny šablon konfigurace a projekty vytvořené provisioningem se auditují — Vytvoření, úprava a smazání šablony konfigurace (…/organizations/{id}/config-templates…) nezapisovaly záznam auditu, stejně jako projekt vytvořený přes POST /api/v1/naming-conventions/{id}/provision. Nyní zapisují záznamy CREATE_CONFIG_TEMPLATE, UPDATE_CONFIG_TEMPLATE (s poli, která úprava použila; úprava, která nepoužije žádné, nezapíše nic) a DELETE_CONFIG_TEMPLATE a CREATE_PROJECT s pojmenovací konvencí a prostředkem, ze kterých projekt vznikl.
Vytvoření šablony konfigurace ignoruje serverová pole v těle — POST /api/v1/organizations/{id}/config-templates převzalo z těla požadavku id, created_at a updated_at, takže klient mohl zvolit ID nové šablony (a kolidovat s existující) nebo ji antedatovat. Server je nyní nastavuje sám; organization_id se již brala z cesty. Úprava již přijímala jen vlastní pole šablony.
Bezpečnost: náhled šablony konfigurace se posuzuje ve své organizaci — POST /api/v1/organizations/{id}/config-templates/preview na rozdíl od ostatních cest šablon konfigurace posuzoval v organizaci z cesty jen org:admin. Nyní nejprve vyžaduje config:write v této organizaci (jinak 403) a neznámá organizace vrací 404 {"error": "Organization not found"} (dříve 403 z kontroly org:admin nebo 404 Project not found).
Bezpečnost: návrhy pravidel pojmenování se posuzují ve své organizaci — GET /api/v1/organizations/{id}/secret-naming-policy/suggest analyzuje klíče secretů organizace z cesty. Nyní i v handleru vyžaduje config:read v této organizaci (jinak 403) a neznámá organizace vrací 404 {"error": "Organization not found"} místo 200 bez návrhů.
Náhled šablony konfigurace už nevrací text selhaného volání Azure — Když Microsoft Graph nebo Azure Resource Manager odmítl volání POST /api/v1/organizations/{id}/config-templates/preview, odpověď 502 nesla v details text chyby tohoto volání včetně těla, které Azure vrátil. Nyní nese pevné details (Microsoft Graph API request failed nebo Azure API request failed) stejně jako cesty pro vyhledávání v Azure a příčina se zapíše do serverového logu s ID požadavku.
Neznámá pravidla synchronizace, konflikty a projekty vracejí 404 — PUT a DELETE /api/v1/projects/sync-rules/{ruleId}, GET …/{ruleId}/conflicts, POST …/{ruleId}/sync, POST /api/v1/projects/sync-conflicts/{conflictId}/resolve a GET, PUT a DELETE /api/v1/projects/{id}/sync-settings odpovídaly na neexistující id kódem 500 (record not found, Failed to get project, …), 200 [], 202 Sync triggered nebo 204, aniž by cokoli změnily. Nyní vracejí 404 s {"error": "Sync rule not found"}, "Sync conflict not found" nebo "Project not found".
Pravidlo synchronizace bez platného cílového prostředí vrací 400 — POST /api/v1/projects/{id}/sync-rules odpovídalo na pravidlo typu pull nebo bidirectional bez target_environment (target_environment is required for pull sync rules) a na target_environment, které není identifikátorem prostředí (invalid target_environment "…": …), kódem 500. Obojí může volající opravit, takže nyní vrací 400 se stejnou zprávou.
Cesty pravidel synchronizace už nevracejí text interních chyb — GET a POST /api/v1/projects/{id}/sync-rules, PUT a DELETE /api/v1/projects/sync-rules/{ruleId}, GET …/{ruleId}/conflicts a POST /api/v1/projects/sync-conflicts/{conflictId}/resolve vkládaly do odpovědi 500 text selhaného volání databáze nebo poskytovatele (například ERROR: invalid input syntax for type boolean u hodnoty špatného typu). Nyní vracejí {"error": "Internal server error"} a příčina je v logu serveru; zprávy 400 u odmítnutého vstupu se nemění.
Vytvoření pravidla synchronizace ignoruje serverová pole v těle — POST /api/v1/projects/{id}/sync-rules převzalo z těla created_at, updated_at, last_sync_at a last_sync_status, takže klient mohl pravidlo antedatovat nebo mu podstrčit smyšlenou neúspěšnou synchronizaci, kterou pak zobrazila stránka Synchronization Problems. Vytvoření je nyní nastavuje samo (aktuální čas, žádná poslední synchronizace); id už předtím generoval server.
Bezpečnost: nastavení synchronizace organizace se posuzuje ve své organizaci — GET a PUT /api/v1/organizations/{id}/sync-settings nyní posuzují organizaci ze své cesty stejně jako ostatní cesty organizace: org:read (u úpravy org:admin) musí platit v této organizaci (jinak 403) a neznámá organizace vrací 404 {"error": "Organization not found"}; dříve čtení vracelo 500 Failed to get organization a úprava 200 Sync settings updated, aniž by cokoli změnila.
Bezpečnost: potvrzení selhání synchronizace a zablokovaného seedu se posuzuje tam, kam patří — POST /api/v1/dashboard/sync/failures/{ruleId}/acknowledge a POST /api/v1/dashboard/sync/blocked-seeds/{incidentId}/acknowledge se posuzovaly jen v prostředí požadavku: kdokoli s sync:write mohl potvrdit selhání a zablokované seedy všech projektů, i v prostředích, která jeho role nepokrývá, a role omezená na projekt nemohla potvrdit žádné. Nyní se posuzují v projektu a cílovém prostředí pravidla, resp. v organizaci, projektu a prostředí incidentu (jinak 403), takže role omezená na projekt potvrdí ta ze svého projektu; neznámé pravidlo nebo incident vrací 404 (Sync rule not found, Incident not found; dříve 500 Failed to acknowledge sync failure, 400 Failed to acknowledge blocked seed).
Bezpečnost: pravidla synchronizace se posuzují ve svém cílovém prostředí — PUT a DELETE /api/v1/projects/sync-rules/{ruleId}, GET …/{ruleId}/conflicts, POST …/{ruleId}/sync a POST /api/v1/projects/sync-conflicts/{conflictId}/resolve se posuzovaly v projektu pravidla, ale v prostředí požadavku, takže role omezená na dev mohla změnit, smazat, spustit pravidlo synchronizující do prod nebo vyřešit jeho konflikty a mohla pravidlo z dev přesměrovat do prod. Nyní se posuzují i v cílovém prostředí pravidla; úprava, která nastavuje target_environment, se posuzuje i v nové hodnotě (prázdná hodnota znamená všechna prostředí), a POST /api/v1/projects/{id}/sync-rules v prostředí, do kterého nové pravidlo míří (jinak 403 insufficient permissions for environment a nic se nezmění). Pravidlo bez cílového prostředí (pravidlo typu push) vyžaduje roli, která není omezená na některá prostředí.
Bezpečnost: pravidlo synchronizace se posuzuje v prostředí své integrace — POST /api/v1/projects/{id}/sync-rules a PUT /api/v1/projects/sync-rules/{ruleId}, pokud mění integration_id, neposuzovaly integraci, přes kterou pravidlo synchronizuje: role omezená na dev mohla vytvořit pravidlo pro dev nad integrací z prod a pravidlo typu pull pak načte hodnoty tajemství z úložiště prod do dev. Nyní navíc vyžadují integration:read v prostředí integrace (jinak 403 insufficient permissions for environment a nic se nezmění).
Bezpečnost: každá změna a spuštění pravidla synchronizace se posuzuje v prostředí jeho integrace — Existující pravidlo pro dev nad integrací z prod (vytvořené rolí oprávněnou v prod) se při úpravě, smazání, spuštění a vyřešení jeho konfliktu posuzovalo jen v cílovém prostředí. Role omezená na dev jej tak mohla přepnout na push, a zapsat tak hodnoty z dev do úložiště prod. PUT a DELETE /api/v1/projects/sync-rules/{ruleId}, POST …/sync-rules/{ruleId}/sync a POST /api/v1/projects/sync-conflicts/{conflictId}/resolve nyní navíc vyžadují integration:read v prostředí integrace pravidla (jinak 403 a nic se nezmění).
Změny nastavení synchronizace a pravidel synchronizace se auditují — PUT /api/v1/organizations/{id}/sync-settings, PUT a DELETE /api/v1/projects/{id}/sync-settings, POST /api/v1/projects/{id}/sync-rules, PUT a DELETE /api/v1/projects/sync-rules/{ruleId} a POST …/{ruleId}/sync nezapisovaly žádný auditní záznam. Nyní zapisují UPDATE_ORG_SYNC_SETTINGS (entita ORGANIZATION, nové hodnoty), UPDATE_PROJECT_SYNC_SETTINGS (entita PROJECT, změněná pole), RESET_PROJECT_SYNC_SETTINGS, CREATE_SYNC_RULE (entita SYNC_RULE, název, směr a cílové prostředí), UPDATE_SYNC_RULE (pole, která úprava použije; žádná, žádný záznam), DELETE_SYNC_RULE (název) a TRIGGER_SYNC_RULE; odmítnuté volání nezapíše nic.
Bezpečnost: seznam a mazání nasazení posuzují organizaci — GET /api/v1/deployments?organization_id= a DELETE /api/v1/deployments/{id}?organization_id= nyní posuzují uvedenou organizaci stejně jako ostatní cesty organizací: jiná organizace než volajícího vyžaduje oprávnění k nasazením v ní (jinak 403 insufficient permissions for organization) a neexistující organizace vrací 404 Organization not found místo prázdného seznamu nebo 404 deployment not found.
Bezpečnost: vytvoření nasazení posuzuje organizaci — POST /api/v1/deployments/ nyní posuzuje organization_id z těla stejně jako seznam a mazání: jiná organizace než volajícího vyžaduje deployment:write v ní (403) a neexistující organizace vrací 404 Organization not found místo 500. Bootstrap token nasazení zapisuje agenty do této organizace, takže už jej nelze vydat pro organizaci, kterou volající nesmí spravovat.
Bezpečnost: politiku viditelnosti prostředků nelze bez org:admin převést — PUT /api/v1/organizations/{id}/config-templates/{templateId} kontroloval org:admin jen pro typ, který by šablona měla po úpravě. Držitel config:write bez org:admin tak mohl poslat {"template_type": "parser", …} pro existující politiku viditelnosti prostředků, a vypnout tak pravidla viditelnosti organizace. Úprava nyní vyžaduje org:admin, je-li politikou viditelnosti stávající šablona nebo nový typ (jinak 403 a nic se nezmění), stejně jako už mazání.
Licence organizace vrací 404 pro neexistující organizaci — GET /api/v1/organizations/{id}/license pro neexistující organizaci vracelo 500 (nebo, byla-li nainstalována licence backendu, tuto licenci) a PUT ověřilo klíč a odpovědělo, jako by byl uložen. Obě cesty nyní vracejí 404 Organization not found a posuzují organizaci z cesty: role omezená na jinou organizaci dostane 403.
Neznámé gatewaye vracejí 404; selhání licence a politiky agentů neukazují interní text — POST /api/v1/admin/gateways/{id}/activate a …/deactivate vracely pro neznámou gatewayi 500; nyní vracejí 404 gateway <id> not found stejně jako čtení gatewaye. PUT /api/v1/organizations/{id}/license vracel při selhání uložení klíče text chyby databáze jako 400; neplatný klíč dál vrací 400 s důvodem, selhání uložení nyní obecnou 500. Odpovědi 500 u POST /api/v1/entra/credentials/{id}/verify-secondary, uložení a čtení politiky verzí agentů a kanálu aktualizací agenta nyní znějí Internal server error a příčinu zapisují do logu serveru.
Nahrání systémového certifikátu a změny licence se auditují — Nahrání systémového TLS certifikátu (POST /api/v1/system/certificate), změna licenčního klíče organizace (PUT /api/v1/organizations/{id}/license) a žádost o obnovení licence (POST /api/v1/license/renew) měnily systém bez záznamu v auditu. Nyní zapisují system_certificate.uploaded (sériové číslo, subjekt a platnost certifikátu), license.key_updated (typ licence; samotný klíč se nikdy nezapisuje) a license.renewal_requested (výsledný stav).
Systémové, licenční a zdravotní cesty už nevracejí text interních chyb; certifikát, který nepatří ke klíči, je 400 — GET /api/v1/health/database při selhání kontroly vracelo v odpovědi 503 text chyby (nyní vrací {"error": "Database health check failed"}) a GET /api/v1/license/status, POST /api/v1/license/renew, GET /api/v1/organizations/{id}/license a GET /api/v1/system/updates/check vkládaly do odpovědi 500 text chyby služby nebo databáze; nyní vracejí Internal server error a příčina je v logu serveru. Nahrání systémového certifikátu (POST /api/v1/system/certificate), jehož privátní klíč k certifikátu nepatří, vracelo 500; nyní vrací 400 se stejnou zprávou (Failed to apply certificate: invalid certificate/key pair: …) a selhání uložení nebo zápisu certifikátu vrací 500 Internal server error.
Interval a plán rotace SSH se ukládají — Dialog rotace SSH posílal požadavky na /api/ssh/rotation…, které neexistuje, takže plán rotace SSH nešlo vytvořit ani změnit, a úprava intervalu na kartě SSH Rotation volala PUT /ssh/rotation-configs/{keyPairId}, které také neexistuje. Dialog nyní používá /api/v1/ssh/rotation a interval se ukládá přes PUT /api/v1/ssh/rotation/{id} (interval_days, status), má-li pár klíčů konfiguraci rotace, jinak přes POST /api/v1/ssh/rotation (key_pair_id, interval_days).
Karta Identities v Access Control vytváří funkční identity služeb — Karta Identities v Access Control posílala name, client_id a role, což backend vždy odmítl (display_name a owner_email jsou povinné), a zobrazovala pole, která identita služby nemá. Karta nyní zobrazuje stejný seznam a formulář jako stránka Service Identities a vyžaduje service_identity:read.
Uložení rotační konfigurace tajného klíče se auditují — PUT /api/v1/secrets/{id}/rotation-config měnilo rotaci tajného klíče (zapnutí, interval, plán, e-maily pro upozornění, cílové prostředí), aniž zanechalo záznam v auditu. Nyní zapisuje rotation_config_updated s novým nastavením; úprava integrace agenta zaznamenává uložené nastavení.
Rotační cesty tajného klíče už nevracejí databázové chyby a neexistující objekty jsou 404 — Rotační konfigurace, propojení, cíle nasazení a seznam integrací projektu při selhání databáze vracely text její chyby a neexistující tajný klíč, integrace nebo integrace agenta končily jako 500 (PUT /secrets/{id}/rotation-config, POST /secrets/{id}/links a /rotation/targets selhaly na cizím klíči a vrátily jeho SQL text; PUT /agent-integrations/{id} vracelo 500). Nyní vracejí pevné tělo „Internal server error“, 404 pro neexistující tajný klíč, integraci či integraci agenta a 409, pokud je tajný klíč propojen se stejnou integrací dvakrát.
Neplatné prostředí při úpravě integrace agenta je 400 — PUT /api/v1/agent-integrations/{id} s prostředím, které není platný slug, vracelo 500 „An unexpected error occurred“. Nyní vrací 400 s důvodem.
Účty ADCS vytvořené ve webovém rozhraní umí vydávat — Webové rozhraní ukládá adresu pro vydávání, režim vydávání, konfigurační řetězec CA, agenta, adresu služby, Verify SSL a časový limit účtu Microsoft ADCS spolu s přihlašovacími údaji, ale poskytovatel ADCS je četl jen z nastavení účtu, takže takový účet vydával bez adresy a každé vydání, načtení certifikátu CA i synchronizace šablon selhaly. Poskytovatel teď tyto hodnoty bere z přihlašovacích údajů všude, kde je nastavení nemá (hodnota v nastavení má dál přednost); stávající účty fungují bez úprav.
Změny rotační konfigurace a neúspěšná obnova zálohy či rotace systémového klíče se auditují — PUT /rotation/configs/{id} měnil plán, interval a prostředí rotace tajného klíče bez záznamu v auditu. Nyní zapisuje rotation_config_updated s nastavenými hodnotami. Obnova zálohy rotace, která selže poté, co začala, zapisuje ROTATION_BACKUP_RESTORE s outcome=failed, a rotace systémového klíče, která selže poté, co ji propustila brána publikace, zapisuje ROTATE_ENCRYPTION_KEY s outcome=failed (typ a účel, nikdy klíč). Pole, která může požadavek nastavit na rotační konfiguraci, jsou explicitní seznam (povoleno, interval, cílové prostředí).
Rotační cesty odpovídají na neznámé objekty 404 a nikdy neukazují chyby databáze — POST /rotation/configs/{id}/preflight pro neznámou konfiguraci odpovídal 500 record not found, POST /rotation/configs pro neznámý tajný klíč selhal na cizím klíči (500 s textem databáze), GET /rotation/executions/{id} odpovídal 404 na jakékoli selhání včetně nefunkční databáze a cesty rotací, záloh a systémových klíčů dávaly do odpovědí 500 text selhávající služby nebo databáze. Pro neznámou konfiguraci, tajný klíč nebo zálohu nyní odpovídají 404 a každá 500 nese jen Internal server error (příčina je v logu serveru). POST /admin/rotation/rotate s typem klíče, který server nezná, odpovídá 400 unsupported key type místo 500.
Spouštění rotace nikdy neukazuje chyby databáze ani služeb — Selhané spuštění rotace (/rotation/configs/{id}/trigger, /rotation/resources/{kind}/{id}/trigger, /secrets/{id}/rotate, /certificates/{id}/rotation/trigger) vkládalo do odpovědi 500 text selhané služby, poskytovatele nebo databáze (například Failed to trigger rotation: …, Sync failed: …). Každá odpověď 500 nyní nese jen Internal server error (příčina je v logu serveru). Cíl nasazení, který nelze přečíst, vrací 500 místo 404 a neznámý Entra credential vrací 404 Entra credential not found místo textu databáze.
Selhané spuštění rotace se audituje — Ruční spuštění rotace, které začalo a pak selhalo (500), nezanechalo žádný auditní záznam, přestože poskytovatel, agent nebo gateway už mohli něco provést. Nyní zapisuje svůj obvyklý záznam (rotation_triggered, u cíle nasazení rotation_deployment_sync_triggered) s outcome=failed a bez textu chyby. Spuštění, které odmítne publish gate, nebo odmítnuté jako neznámé či konfliktní, se jako spuštění neaudituje.
Obnovená rotace přežije zavřenou záložku prohlížeče — POST /rotation/executions/{id}/resume spouštěl zbývající kroky na spojení požadavku: když klient odešel (zavřená záložka, timeout proxy), kroky se zastavily uprostřed rotace a zámek běhu nešlo uvolnit, takže každé další obnovení vracelo až 10 minut 409 „already in progress“. Obnovení nyní doběhne do konce a uvolní svůj zámek bez ohledu na spojení.
Seznam běhů rotace ukazuje nejnovější běhy organizace — GET /rotation/executions načetl 100 nejnovějších běhů celé instalace a teprve pak ponechal běhy organizace volajícího, takže organizace, jejíž běhy nepatřily mezi 100 nejnovějších celkově, viděla zkrácený nebo prázdný seznam. Organizace se nyní filtruje před limitem: seznam obsahuje 100 nejnovějších běhů organizace (a z nich čitelná prostředí).
Podepsání SSH klíče bez uživatele odpovídá 401 — POST /api/v1/ssh/sign pro principála bez uživatele odpovídal 500 (vydavatel certifikátu je cizí klíč na uživatele). Nově odpovídá 401 authentication required stejně jako create-and-deploy.
Export soukromého SSH klíče vrací PEM a rotace SSH klíče zachovává typ klíče — Export RSA klíčového páru vytvořeného přes create-and-deploy vracel surová binární data místo PEM soukromého klíče; každý export nově vrací PEM (starší uložené klíče se převádějí při čtení, nové se ukládají jako PEM). Rotace SSH klíčového páru vždy generovala RSA 4096; nově zachovává typ (RSA, Ed25519 nebo ECDSA) i velikost klíčového páru.
Šablony rotací fungují s API tokeny — Trasy šablon rotací (/api/v1/rotation/templates) četly organizaci jen z UI session, takže každý API token (Terraform, CLI, SDK) dostal 403 record not found. Token nově funguje ve své organizaci stejně jako session a šablony jiné organizace zůstávají 404.
Rotation Problems zobrazují incident a informaci o nahrazení — Pole incident_id, incident_status a superseded_at v GET /api/v1/dashboard/rotation/failures se nikdy nevyplňovala: dotaz používal neplatné SQL a jeho chyba se zahazovala. Nově obsahují navázaný incident selhané rotace a dokončení pozdější úspěšné rotace a selhání dotazu odpoví 500 místo tichého vynechání.
Podepsání SSH klíče funguje a vytvoření s nasazením pro Ed25519 i import Ed25519 klíče ve formátu OpenSSH už nepadá — POST /api/v1/ssh/sign vždy odpovídal 500 (certifikát se ukládal bez vydavatele), POST /api/v1/ssh/keys/create-and-deploy odpovídal 500 pro nabízený typ Ed25519 a POST /api/v1/ssh/keys/import odmítal klíč Ed25519 ve formátu OpenSSH, který zapisuje ssh-keygen. Všechny tři nově uspějí; nečitelný veřejný klíč odpovídá 400, neznámý projekt 404 a každé podepsání se zapisuje do auditu (SIGN_SSH_KEY).
Trasy SSH klíčů už nevracejí databázový text a pro neznámý nebo duplicitní vstup odpovídají 404/409 — Vytvoření klíčového páru bez project_id nebo pro neznámý projekt, import klíče, jehož otisk už existuje, nasazení autorizovaného klíče na neznámého agenta a každé další selhání čtení či zápisu tras SSH klíčů a autorizovaných klíčů odpovídalo 500 (nebo 400) s textem databázové chyby. Nově odpovídají 400 (chybějící project_id, nepodporovaný typ klíče), 404 (neznámý projekt, uživatel nebo agent) a 409 (klíč už je naimportován); ostatní selhání odpovídají 500 Internal server error a jsou zalogována.
Export neexistujícího soukromého SSH klíče odpovídá 404 — POST /api/v1/ssh/keys/{id}/export odpovídal pro neexistující id (i pro volajícího bez ssh:admin) 500 s databázovou chybou. Nově odpovídá 404 a 403; odpověď zůstává necachovatelná a jediný auditní záznam ssh_key.export eviduje výsledek a nikdy samotný klíč.
Šablony rotace: vytvoření z konzole už nekončí chybou — Uložení nové šablony rotace s poli, která formulář odesílá (název, popis, číselné hodnoty politiky, příznak výchozí), končilo odpovědí 500, protože seznamy upozornění a kroků workflow se ukládaly jako null. Nově se ukládají prázdné a šablona se vytvoří (201).
Žádost o certifikát: pole Stát/Kraj se nově použije — Hodnota zadaná do pole State/Province ve formuláři žádosti se odesílala jako province, které backend ignoruje, takže se nikdy nedostala do subjektu certifikátu. Nově se odesílá jako state a objeví se v požadovaném subjektu.
OCSP odpovídá i pro nezneplatněné certifikáty — Responder hledal vydávající CA ve sloupci, který neexistuje, takže každé sériové číslo bez záznamu o zneplatnění dostalo HTTP 500 a odpovídalo se jen na zneplatněné certifikáty. Certifikát vydaný CA nyní dostane stav good; sériové číslo, které CA nikdy nevydala, stále vrací revoked (certificateHold).
ACME klienti mohou opět posílat POST na ACME server — Kontrola CSRF odmítala každý ACME POST (new-account, new-order, finalize, ...) s 403 CSRF token mismatch, protože ACME klienti jako cert-manager neposílají prohlížečový token. /api/acme/ je nyní vyňato, stejně jako /api/v1/scep/; každý ACME požadavek je dále ověřen podpisem JWS.
Inicializace nebo smazání interní CA již nemůže zablokovat server — Zámek operací s interní CA držel pro každý čekající požadavek jedno databázové spojení, zatímco držitel zámku potřeboval další, takže dostatek souběžných volání vyčerpal pool spojení a zablokoval všechny požadavky. Pár klíčů se nyní generuje před zámkem a vše pod zámkem běží v jedné transakci; souběžná volání pro jednu organizaci stále vytvoří právě jednu CA (ostatní vrátí 409).
Zablokované HSM zařízení se testuje jednou, ne při každém cyklu — Monitor zdraví vzdal sondu, která neodpověděla do 30 sekund, a označil zařízení jako nedostupné, ale další cyklus zahájil další sondu téhož zařízení, zatímco první stále visela; zařízení, které zůstalo zablokované, tak každou minutu přidalo vlákno (u PKCS#11 modulu vlákno operačního systému), dokud serveru nedošla vlákna. Zařízení, jehož předchozí sonda neskončila, se přeskočí a zůstane nedostupné; znovu se testuje, jakmile volání skončí.
Interní CA: neznámá organizace vrací 404, parametry jsou omezené, souběžná inicializace vytvoří jednu CA — Čtení interní CA neznámé organizace vracelo 204 a její inicializace 500 poté, co vygenerovala CA, na kterou nic neodkazovalo; obojí nyní vrací 404 a nic nevytváří. validity_years nad 100, RSA key_size nad 8192 (server byl dlouho zaneprázdněn generováním klíče) a common_name delší než 255 znaků vrací 400. Inicializace, oprava (initialize-ca) a smazání interní CA jedné organizace probíhají postupně, takže dvě současné inicializace už nevytvoří dvě kořenové CA (jedna vrátí 201, druhá 409) a smazání se neopakuje.
ACME EAB přihlašovací údaje: chyby vracejí 400 nebo 404 místo 500 a vytvoření i zneplatnění se auditují — Vytvoření údajů bez project_id (400), s neznámým projektem či šablonou (404) nebo s popiskem delším než 255 znaků (400) vracelo 500 s textem databázové chyby; každá chyba nyní vrací pevný text bez databáze. Vytvoření i zneplatnění zapisuje auditní záznamy CREATE_EAB_CREDENTIAL a REVOKE_EAB_CREDENTIAL (jednorázový HMAC klíč v nich není). Zneplatnění již zneplatněných údajů vrací 409 místo 200.
Navazující úpravy certifikátů: kontrola stavu používá nastavení účtu, přepínače TLS vyžadují přihlašovací údaje — Plánovaná kontrola stavu externě vydaných certifikátů nově čte nastavení účtu stejně jako synchronizace (dříve použila výchozí hodnoty poskytovatele). Změna verify_ssl, insecure_skip_tls nebo tls_config účtu CA vyžaduje opětovné zadání přihlašovacích údajů, stejně jako změna URL. Převzetí objeveného certifikátu, který odpovídá více spravovaným, nově preferuje i certifikát bez projektu ve stejném prostředí. Výpis zařízení HSM při chybě vrací prostou 500 bez textu chyby a s identifikátorem požadavku v logu.
Nedostupné zařízení HSM už nezastaví ani neshodí kontrolu stavu — Kontrola stavu procházela zařízení postupně bez časového limitu a bez ochrany proti panice: zařízení, které neodpovědělo (zablokované volání PKCS#11), zastavilo kontrolu všech ostatních, a provider, který zpanikařil, shodil celý server. Každá kontrola má nově limit 30 sekund a vlastní obnovu; zařízení, které vyprší nebo zpanikaří, se označí jako nezdravé a kontrola pokračuje.
Vstupy účtu CA jsou omezené a duplicitní jméno vrací 409 — Interval synchronizace účtu CA je omezen na rok (525600 minut) a předstih obnovy na 3650 dní: větší hodnoty přetékaly čas příští synchronizace, takže plánovač synchronizoval při každém taktu. Zobrazované jméno delší než 255 znaků vrací 400 a připojení nebo přejmenování účtu na jméno, které už používá účet téže organizace a téhož typu poskytovatele, vrací 409; obojí dříve vracelo 500.
Synchronizace účtu CA používá jeho nastavení — Synchronizace účtu CA (tlačítko Synchronizovat i plánovač) ignorovala nastavení účtu, takže účet SSLmarket s jinou base_url se vždy synchronizoval proti produkčnímu API: tlačítko vracelo 500 a účet se označil jako chybný. Synchronizace nyní inicializuje poskytovatele stejným nastavením jako objednávání a synchronizace produktů.
Změny zařízení HSM a politik obnovy se auditují na volajícího — Vytvoření, úprava a smazání zařízení HSM se zapisovalo pod systémového uživatele bez adresy volajícího a změny politik obnovy se nezapisovaly vůbec. Každá změna je nově záznam auditu uživatele, který ji provedl, s adresou (konfigurace zařízení se v něm nikdy neobjeví).
Chyby politik obnovy neobsahují text databáze — Vytvoření politiky obnovy pro neexistující organizaci vrací 404 (dříve 500 s cizím klíčem databáze); selhání výpisu, vytvoření, úpravy a smazání vrací obecné 500.
Test zařízení HSM nevrací text chyby poskytovatele — Tlačítko Test vracelo v error surový text chyby poskytovatele (s adresou, kterou server volal, a tím, co odpovědělo). Nyní vrací pevný text (zařízení nelze zkontaktovat nebo má neplatnou konfiguraci; zařízení neodpovědělo na výpis klíčů) a podrobnosti jdou do logu serveru.
Odmítnutí zařízení HSM jsou srozumitelná místo textu databáze — Vytvoření nebo přejmenování zařízení HSM na jméno, které už v organizaci existuje, vrací 409 (dříve 400 s názvem omezení databáze), vytvoření pro neexistující organizaci 404 a neočekávané selhání 500 bez textu. Smazaná zařízení si jméno ponechávají.
Zařízení HSM typu PKCS#11 s nenačitelným modulem už nezhroutí test ani kontrolu stavu — Test zařízení PKCS#11, jehož knihovnu modulu nelze načíst, dereferencoval nil ukazatel: tlačítko Test vracelo 500 a kontrola stavu na pozadí (která se z paniky neobnovuje) mohla zastavit celý server. Zařízení se nyní hlásí jako nedostupné.
Úprava prostředí nebo funkčních skupin zařízení HSM už nepadá — PUT /api/v1/organizations/{id}/hsm-devices/{deviceId} s environments nebo applies_to (tato pole posílá Go SDK) vracel 400 s textem databáze a nic neuložil. Seznamy se nyní ukládají, prázdný seznam znamená vše a applies_to se ověřuje jako při vytvoření (400 „invalid scope tag“).
Chyby vstupu účtu CA vracejí 400 nebo 404 místo 500 — Připojení nebo úprava účtu CA s přihlašovacími údaji či nastavením, které CA odmítne, s nepodporovaným typem poskytovatele nebo neplatným ca_authority_id vracely 500 „Failed to connect account“ nebo „Failed to update account“; stejně dopadlo připojení s neplatným ID organizace v cestě a GET /api/v1/ca-providers/{type}/schema pro neznámý typ poskytovatele. Nově vracejí 400 („The connection to the CA failed: check the credentials and settings“, „unsupported provider type: …“, „Invalid ca_authority_id“, „Invalid organization ID“) a 404 („CA provider not found“). Odpověď CA není nikdy součástí odpovědi (může pocházet z libovolného hostitele, na který nastavení ukazuje) a do logu se zapisuje bez hodnot přihlašovacích údajů.
Synchronizace produktů účtu CA už nehlásí chybu — POST /api/v1/organizations/{id}/ca-accounts/{accountId}/products/sync (i starší /api/v1/ca-accounts/{id}/sync) vracelo 500 u každého poskytovatele, který uvádí velikosti klíčů nebo algoritmy, a stejně selhalo i čtení uložených produktů: povolené velikosti klíčů a algoritmy se do polí v PostgreSQL ukládaly jako text JSON. Nově se ukládají a čtou jako pole, takže se katalog produktů načte a formulář žádosti produkty nabídne.
Import certifikátů už neposílá interní text chyb a špatný privátní klíč vrací 400 — Routy importu (POST /api/v1/certificates/import, /import/bulk, /import/file, /import/preview-multi) vracely 500 se surovým textem chyby serveru (například hláškou databázového omezení) a položky hromadného importu nebo importu souboru jej nesly v odpovědi 200. Nově vracejí 500 s obecnou zprávou (příčina jde do logu serveru s ID požadavku) a takovou položku označí Failed to import certificate. Privátní klíč, který neodpovídá certifikátu, soubor obsahující jen klíč a certifikát, který nepatří k cílovému, jsou chyby vstupu a vracejí 400 s důvodem místo 500.
Odeslání žádosti o certifikát se vstupem, který server odmítne, vrací 400 nebo 404 — POST /api/v1/certificates/csr vracelo 500 („Failed to submit CSR“) pro CSR, které nelze přečíst, má neplatný podpis nebo porušuje pravidla šablony pro velikost klíče či SAN, pro nepodporovaný csr_source_mode, neexistující šablonu a neexistující přepsání CA účtu. Nově vrací 400 s důvodem u prvních tří a 404 pro neexistující šablonu nebo CA účet; stejné texty se objeví i u projektové routy pro CSR.
Rozhodnutí o neexistující nebo už rozhodnuté žádosti o certifikát vrací 404 nebo 409 — Schválení, zamítnutí nebo archivace žádosti o podpis certifikátu (POST /api/v1/certificates/csr/{id}/approve, /reject, /archive) vracely 500, pokud žádost ve vaší organizaci neexistovala, už byla schválena, zamítnuta nebo archivována (například ze zastaralého seznamu), nebo ji ve stejnou chvíli rozhodl někdo jiný. Nově vracejí 404 pro neexistující žádost a 409 pro žádost, která už není čekající (nebo je již archivovaná), nic se nezmění a dva schvalovatelé rozhodující o téže žádosti současně vydají certifikát jen jednou.
Import privátního klíče objeveného certifikátu už neukazuje databázové chyby — POST /api/v1/discovered-certificates/{id}/import-key vracel 400 se surovým textem chyby selhávajícího čtení nebo zápisu do databáze (například text SQL chyby) stejně jako u nečitelného nebo neodpovídajícího klíče. Selhání čtení nebo uložení certifikátu či zápisu do auditního logu nově vrací 500 s obecným Internal server error a příčina jde do logu serveru; chyby samotného klíče (není PEM klíč, špatné heslo, klíč neodpovídá certifikátu) dál vracejí 400 s důvodem.
Změny objevených certifikátů se auditují — Přiřazení, adopce, ignorování a archivace objeveného certifikátu, import jeho privátního klíče a hromadné přiřazení, adopce a ignorování (/api/v1/discovered-certificates/...) zapisovaly jen do certifikátového auditu služby, takže auditní log o nich nic neukazoval. Každé úspěšné volání nově zapíše i jeden auditní záznam (discovered_certificate_assigned, _adopted, _ignored, _archived, _key_imported, discovered_certificates_bulk_assigned, _bulk_adopted, _bulk_ignored) s uživatelem, certifikátem a u přiřazení nebo adopce i projektem. Odmítnuté volání, neznámý certifikát a hromadná adopce, která nic nepřijala, nezapíší nic, a import klíče nikdy nezaznamenává klíč ani jeho heslo.
Obnovení a trvalé smazání odmítnou archivovaný objevený certifikát nebo žádost o certifikát, který je neznámý nebo není archivován — Obnovení nebo trvalé smazání archivovaného objeveného certifikátu či žádosti o certifikát (/api/v1/archived/discovered-certificates/{id}/restore, /permanent a /api/v1/archived/certificate-requests/{id}/restore, /permanent), který neexistuje nebo byl mezitím obnoven, vracelo 500 s textem chyby. Nově vrací 404 (record not found) pro neznámý řádek a 409 (discovered certificate is not archived, certificate request is not archived) pro řádek, který není archivován, a nezapíše záznam do auditu. Trvalé smazání nově řádek zamkne a v transakci znovu ověří, takže obnovení, které se potvrdí dřív, vyhraje a řádek se nesmaže; ostatní selhání vrací obecné Internal server error.
Neznámé a zastaralé objevené certifikáty vracejí 404 a 409 místo 500 — Přiřazení, ignorování, archivace nebo import klíče u objeveného certifikátu, který už neexistuje nebo byl mezitím archivován (/api/v1/discovered-certificates/{id}/assign, /ignore, /archive, /import-key), vracely 500 record not found, stejně tak ignorování už spravovaného certifikátu (invalid state transition). Nově vracejí 404 Certificate not found, nebo 409, když stav změnu nedovoluje nebo je certifikát už archivován. Hromadné přiřazení a ignorování nejdřív zkontrolují všechny certifikáty, takže požadavek s neznámým nebo spravovaným certifikátem nezmění žádný z nich (dříve se změnily ty uvedené před ním).
Routy objevených certifikátů už neposílají interní text chyby — Když selhala databáze, přiřazení, ignorování nebo archivace objeveného certifikátu (POST /api/v1/discovered-certificates/{id}/assign, /ignore, /archive), hromadné přiřazení a ignorování, statistiky objevování a seznam archivovaných certifikátů vracely 500 se surovým textem chyby služby. Nově vracejí 500 s obecným Internal server error a příčina jde do logu serveru s ID požadavku.
Režim orchestrátoru vrací 409 pro zápisy, které nelze provést — Import secretů projektu (POST /api/v1/projects/{id}/secrets/import) v režimu orchestrátoru a uložení hodnoty přes PUT /api/v2/secrets/{id} nebo POST /api/v2/secrets/migrate u secretu names_only vracely 500. Nyní vracejí 409 s důvodem (například „import is not supported in Orchestrator Mode“) a migrace odmítne dřív, než změní jakýkoli secret, stejně jako už rollback a kopírování.
Úprava poskytovatele identity mohla přepsat uložené tajemství — PUT /api/v1/identity-providers/{id} ukládal tajná pole konfigurace tak, jak přišla. Předchozí konzole posílala zpět zobrazenou masku ****, která nahradila skutečný client_secret Entra ID a rozbila přihlášení, a úprava, která tajemství vynechala nebo nechala prázdné, je smazala. Úprava nyní ponechá uložený client_secret, bind_password, api_token a token, pokud je nová hodnota prázdná, chybí, je __MASKED__ nebo začíná ****; jiná hodnota jej nahradí. U poskytovatele, u kterého už byla maska uložena, je třeba tajemství zadat znovu.
Akce v archivu nad neexistující nebo aktivní položkou končily interní chybou — Obnovení nebo trvalé smazání uživatele, který už neexistuje (například jej mezitím odstranil jiný administrátor), a trvalé smazání uživatele, který není smazaný, vracely 500 na POST /api/v1/archived/users/{id}/restore a DELETE /api/v1/archived/users/{id}/permanent; totéž platilo pro archivaci, obnovení a trvalé smazání neexistujícího projektu (/api/v1/projects/{id}/archive, /restore, /permanent), kde obnovení neexistujícího projektu dokonce vracelo 200. Nyní vrací 404 (record not found) pro neexistujícího uživatele nebo projekt a 409 pro aktivního uživatele, se stejnými texty chyb.
Vytvoření uživatele s neplatným heslem nebo již existujícím e-mailem končilo interní chybou — POST /api/v1/rbac/users vracel 500 s obecnou zprávou, když heslo nesplňovalo politiku hesel nebo uživatel se stejným e-mailem již existoval, takže stránka Řízení přístupu mohla zobrazit jen obecné selhání. Nyní vrací 400 s textem politiky (například password must be at least 8 characters long) a 409 (user already exists).
Politiky schvalování nešlo vytvořit bez podmínek — POST /api/v1/projects/{id}/approval-policies vracel 500 (cannot unmarshal array into Go value of type map[string]interface {}), kdykoli požadavek neobsahoval conditions, což posílá Go SDK i resource approval_policy Terraform provideru, takže každé takové vytvoření selhalo. Chybějící conditions se nyní nastaví na prázdný objekt a politika se vytvoří.
Schválení nebo zamítnutí již vyřízené žádosti o schválení končilo interní chybou — POST /api/v1/projects/approval-requests/{requestId}/approve a /reject vracely 500, když žádost už nebyla ve stavu čekající, když uživatel u žádosti vyžadující více schvalovatelů už hlasoval (tlačítko Schválit zůstává v takovém případě viditelné), nebo když žádost neexistovala. Nyní vrací 409 (request is not pending, already voted) a 404 (record not found) se stejnými texty chyb.
Štítky projektu a webhooky notifikací nešly uložit — PUT /api/v1/projects/{id}/settings vracel 500 s textem databázové chyby, kdykoli tags nebo notification_webhooks obsahovaly alespoň jednu položku, protože se seznamy zapisovaly ve špatném formátu pro sloupce typu JSON (prázdný seznam se ukládal jako objekt místo pole). Oba seznamy se nyní ukládají jako pole JSON a GET /api/v1/projects/{id}/settings je vrací beze změny. Projekt, u kterého se prázdný seznam už uložil ve starém formátu, nešlo dále otevřít a jeho přítomnost rozbíjela seznam projektů v celé instanci; migrace 000211 takové projekty při aktualizaci opraví.
Změna stavu prostředí končila interní chybou — PATCH /api/v1/projects/{id}/environments/{env}/state vracel 500 pro každé prostředí, které má nastavení, protože změna se zapisovala pro neexistujícího (nil) uživatele, což porušuje cizí klíč last_modified_by. Změna se nyní zapisuje na přihlášeného uživatele (i do auditního logu aktualizace nastavení prostředí), takže zapnutí, vypnutí nebo označení prostředí jako neexistujícího funguje. Volání autentizovaná tokenem service identity nadále selhávají, protože last_modified_by odkazuje pouze na uživatele.
Compose kit nenastartoval: databáze bez TLS, dokumentace bez HTTPS — Při výchozím MAZEVAULT_ENV=production backend odmítá připojení k databázi bez TLS, ale PostgreSQL dodávaný s kitem běžel bez TLS (sslmode=disable), takže backend se nikdy nestal zdravým; kontejner dokumentace naslouchal jen na portu 80, zatímco kit publikoval a kontroloval HTTPS. PostgreSQL v kitu nyní používá TLS s certifikátem z volume certs a backend i OCSP responder se připojují s sslmode=require; kontejner dokumentace obsluhuje HTTPS na portu dokumentace kitu (DOCS_PORT, výchozí 8088), je-li připojen certifikát, jinak prosté HTTP na portu 80 (Helm beze změny). Stávající Compose instalace změnu převezmou spuštěním instalátoru z nového kitu, který nainstaluje jeho docker-compose.yml a ponechá stávající .env i datové volumy (stejně tak upgrade-mazevault.sh z nového kitu).
Stažení CRL ve formátu DER vracelo prázdné tělo — GET /api/v1/ca/{id}/crl (výchozí format=der) odpovídal 200 s hlavičkami pro DER, ale bez obsahu; CRL vracel jen format=pem. Endpoint nyní vrací CRL v kódování DER, dekódovaný z uloženého PEM.
Vestavěné role ztrácely oprávnění přidaná při upgradu — Backend při každém startu přepsal oprávnění vestavěných rolí starším pevným seznamem, takže oprávnění přidaná migracemi zmizela po prvním restartu: report:read/report:write, keytab:read (User, Secret Manager), dashboard:write, agent:admin, audit:read, config:read a project:write (Certificate a Secret Manager) a token:read. Stejně se přepisovaly i úpravy vestavěných rolí provedené zákazníkem. Backend nyní pouze zakládá chybějící role a existující nemění; migrace 000207_restore_system_role_permissions obnoví zamýšlená oprávnění. Zároveň přidělí token:read/token:write/token:delete rolím Project Admin a Secret Manager (migrace 000193 je přidělovala rolím, které už neexistují). Migrace oprávnění pouze přidává a žádná neodebírá, takže stávající přiřazení rolí i úpravy zákazníka zůstávají zachovány.
Nasazení do keystore přes agenta posílalo balíček, který agent neuměl přečíst — Orchestrovaný krok agent_keystore_sync předával agentovi jediný blob exported_data, zatímco agentův CertificateSyncBundle očekává certificate_pem, private_key_pem a chain_pem; každá rotace do JKS / PKCS#12 / Windows store proto na agentovi selhala s failed to decode certificate PEM a řetězec CA se nikdy nedostal do trust store. Všichni konzumenti nasazení (Kubernetes secret, Key Vault, agent keystore, agent file, Oracle wallet) nyní rozdělují export jediným sdíleným helperem — první certifikát = leaf, další certifikáty = řetězec vydavatelů, klíč zvlášť — který přijímá i base64 podobu po průchodu gateway, a keystore krok posílá přesně ta pole, která agent deserializuje (včetně post_install_command, dříve vnořeného na špatném místě). Jde o opravu pouze na straně backendu/gateway, kompatibilní s již nasazenými agenty.
Kroky rotace agent_command končily timeoutem u každého agenta — Krok přeposílal HTTP požadavek přes typ proxy zprávy, který agent nikdy neimplementoval, takže restarty služeb a další příkazové kroky čekaly 30 s a selhaly. Krok nyní používá požadavek agenta agent_command (vynucený allowlist) a respektuje timeout_seconds.
Cíle Agent File, WebLogic a Oracle wallet se nedaly provést — agent_file_sync, agent_file_backup a weblogic_restart builder workflow generoval, ale nikdy nebyly registrovány (unknown step type), a registrované kroky weblogic_deploy / oracle_wallet_deploy vracely executed, aniž by kontaktovaly jakýkoliv hostitel. Tyto cíle nyní běží přes skutečné registrované kroky (viz Nové funkce); sloučené typy kroků weblogic_restart a agent_file_backup jsou odmítnuty s pokynem znovu vytvořit cíl nasazení místo hlášení falešného úspěchu.
Cíle Web Server a Load Balancer byly tiše přeskakovány — Builder workflow neměl větev pro cíle web_server a load_balancer, takže rotace s takovým cílem hlásila úspěch, aniž by cokoliv nasadila. Nyní jsou při uložení odmítnuty a u již existujících selže sestavení workflow s explicitním důvodem (viz Cíle nasazení se validují při uložení).
Cíl Database Wallet šel vytvořit bez agenta — UI označovalo Database Wallet jako cíl nevyžadující agenta, přestože nasazení spouští orapki na databázovém hostiteli přes agenta; takové cíle se nikdy nemohly provést. UI i API nyní pro tento typ cíle agenta vyžadují a aktualizace cílů posílané jako JSON dokumenty se explicitně serializují na každém databázovém driveru (GORM u map-based update nespouští serializátory polí; driver Postgres strukturu shodou okolností zakódoval, SQLite ji odmítla).
Cíl Windows windows_root importoval privátní klíč do úložiště důvěryhodných kořenů — Windows keystore installer sestavoval PFX s privátním klíčem pro každé úložiště a jako cestu k úložišti používal surový typ keystore (windows_root), což není platný název Windows store. Cíle windows_root a windows_ca nyní instalují pouze veřejné certifikáty (leaf do určeného úložiště, řetězec klasifikovaný do Root / CA), windows_my dostává PFX leaf + klíč bez řetězce a typy keystore se mapují na skutečné názvy úložišť My / Root / CA. Backend tomu odpovídá: krok agent_keystore_sync už pro windows_root / windows_ca nevyžaduje privátní klíč (CA certifikát bez klíče lze nyní nasadit do trust store) a private_key_pem pro tato úložiště do bundle nikdy nevkládá, ani když ho export obsahuje; JKS / PKCS#12 / windows_my bez klíče nadále selžou rychle. Hodnota UI Windows Cert Store (keystore_type: windows) nikdy neodpovídala ničemu, co agent přijímá; editor nyní nabízí explicitně Windows — Personal (My), Trusted Root CAs a Intermediate CAs (bez cesty, aliasu a hesla úložiště pro Windows store), uložené cíle se starší hodnotou windows se při provádění kanonizují na windows_my a cíle agent_keystore se validují při uložení (JKS / PKCS#12 potřebují keystore_path; neznámé typy úložiště jsou odmítnuty).
Starší záznamy mohly exportovat jako leaf špatný certifikát — Certifikáty importované před zavedením leaf_certificate_pem mají v raw_certificate_pem přesně to, co bylo nahráno — může jít o bundle „root, leaf“; nový resolver řetězce zpočátku četl toto surové pole dříve než public_chain_pem (vždy leaf-first), takže by takový záznam exportoval, zobrazoval a nasazoval CA certifikát jako leaf (a hlásil prázdný, úplný řetězec). Leaf se nyní vybírá podle uloženého SHA-256 thumbprintu záznamu bez ohledu na pozici v uloženém materiálu; bez thumbprintu platí dosavadní pořadí (vyhrazené pole leaf → první blok public_chain_pem → surový upload → DER). Kryto regresním testem s root-first surovými bundly pro end-entity i CA záznamy.
Discovery slučovala více end-entity certifikátů z jednoho souboru — Agent hlásí jeden záznam na každý end-entity certifikát nalezený v PEM souboru, ale jako tělo posílá celý soubor; backend bundle normalizoval heuristikou „první ne-CA blok“, takže soubor se dvěma end-entity certifikáty (starý + obnovený, server + klient) oba reporty sloučil do prvního certifikátu a druhý se nikdy nezaznamenal. Nahlášený fingerprint nyní vybírá leaf uvnitř bundle, sourozenecké end-entity certifikáty jsou z řetězce tohoto leafu vyloučeny a heuristika se použije jen tehdy, když žádný blok neodpovídá.
Nasazení do osobního úložiště Windows vyžadovalo heslo keystore, které neexistuje — Úložiště Windows My žádné heslo keystore nemá; agent ho potřebuje jen k zabalení dočasného PFX, který na hostiteli importuje a smaže, a PowerShell prázdnou hodnotu odmítne. Cíle typu windows_my bez nakonfigurovaného hesla proto při instalaci selhávaly. Krok agent_keystore_sync nyní vygeneruje jednorázové náhodné heslo PFX, pokud žádné není nakonfigurováno (nikdy se neloguje ani nepersistuje a heslo zadané operátorem je nadále respektováno), takže pro Windows úložiště není třeba zakládat žádný bezvýznamný secret. Na agentovi se heslo PFX předává PowerShellu přes prostředí procesu místo vkládání do skriptu, takže heslo s uvozovkami nebo $ nemůže import rozbít ani být vypsáno zpět v chybě. Pokud nasazení běží přes gateway, odvozuje se jednorázové heslo z idempotency klíče kroku, takže opakovaný pokus předloží identický bundle a agent dokončenou instalaci přehraje místo jejího odmítnutí jako jiné operace. Názvy Windows úložišť agent řeší jedním sdíleným pravidlem: My a jakýkoliv prostý název LocalMachine úložiště nalezený nebo nakonfigurovaný na hostiteli (např. WebHosting, výchozí úložiště IIS na současném Windows Serveru) jsou identity úložiště, která dostanou PFX; Root, CA, AuthRoot, TrustedPublisher a Disallowed jsou trust-anchor úložiště, která dostanou pouze veřejné certifikáty — privátní klíč se do nich nikdy neimportuje, a to ani cestou obnovy či starších metadat; bundle, který pro trust-anchor úložiště nese privátní klíč, je odmítnut s explicitní chybou místo poloviční instalace (obnovený klíč by se jinak tiše ztratil). Názvy, které by mohly změnit PowerShell skript, jsou odmítnuty. Funguje s již nasazenými agenty (samotná změna backendu instalaci opraví).
Kandidáti vydavatelů z inventáře nebyli identifikováni podle thumbprintu — Vyhledávání vydavatelů v resolveru řetězce nenačítalo thumbprint_sha256 u kandidátních CA záznamů, takže výběr leafu podle thumbprintu zavedený výše se na ně nevztahoval a starší podřízená CA uložená root-first se jako vydavatel nikdy nenabídla (řetězec zůstal neúplný — bezpečné, ale doplnění neproběhlo). Sloupec se nyní načítá a regresní test pokrývá kandidáta uloženého root-first.
Import privátního klíče přijal libovolný klíč k certifikátu bez těla — POST /discovered-certificates/{id}/import-key přeskakoval kontrolu shody klíče a certifikátu, když spravovaný certifikát neměl uložené tělo (podoba, kterou před touto verzí produkovala každá adopce), takže se mohl tiše uložit nesouhlasící klíč a selhat až při nasazení. Import nyní takový požadavek odmítne s explicitní chybou, dokud tělo neexistuje.
Připojení klíče ke spravovanému certifikátu bez těla ho nechalo bez těla — Update cesta importu připojila klíč, ale na záznamy bez těla neuložila leaf PEM / DER; nyní tělo připojí, zachová bohatší uložený řetězec a chybějící řetězec doplní z inventáře.
Import certifikátu bral identitu z prvního PEM bloku — Bundly v pořadí root, intermediate, leaf (jak je vydávají některé nástroje) byly zaznamenány s common name, serialem a otiskem rootu, zatímco uložené tělo byl leaf. Identita a metadata se nyní odvozují z normalizovaného leafu bez ohledu na pořadí bloků.
Import více souborů zahazoval samostatné soubory s klíčem — Nahrání certifikátu spolu se samostatným .key souborem klíč tiše zahodilo (UI tvrdilo, že byl spárován při náhledu) a importovalo pouze certifikát, takže opakovaný import spravovaného certifikátu za účelem doplnění klíče vždy skončil chybou „already exists“. Klíč se nyní páruje na backendu a importuje společně s certifikátem.
Rotace tajemství už neselhává na cizím klíči zálohy — Každá rotace tajemství padala v ságe na pozadí s insert or update on table "rotation_backups" violates foreign key constraint "rotation_backups_execution_id_fkey". Záloha před rotací vznikala dříve, než existoval řádek exekuce rotace, a nikdy nenastavila execution_id, takže nenulový cizí klíč insert odmítl a žádná rotace nemohla proběhnout. Záloha se nyní vytváří uvnitř exekuce (po runtime probe, před prvním mutujícím krokem) s platným execution_id a rozřešení organizace je ověřeno předem. Regrese byla neviditelná, protože testovací harness SQLite nevynucuje cizí klíče a omezení existuje jen v SQL migraci; reálnou insert cestu nyní pokrývá test s vynuceným cizím klíčem.
Migrace rotačních šablon korektně zpracují nová pole politiky — Perzistenční cesta rotačních šablon a její migrace byly opraveny tak, aby nově přidaná pole politiky (lead_time_days, grace_period_days, secret_custody_mode) konzistentně kolovala mezi API, SDK, providerem a uloženým katalogem.
Aktualizace rotační šablony už nepadá při částečných úpravách — Dekodér požadavku create/update rotační šablony dereferencoval typované nil ukazatele, takže jakýkoli požadavek, který vynechal volitelné pole — běžný případ u úpravy jediného pole, například změny pouze intervalu — způsobil paniku a vrátil HTTP 500. Dekodér nyní rozlišuje přítomnost: vynechaná pole se přeskočí, explicitní 0 nebo false se zachová jako zamýšlená hodnota a project_id lze nastavit, změnit nebo vymazat (explicitním null) bez dopadu na ostatní pole.
Vyřazení agenti se mohou znovu zaregistrovat autorizovaným náhradním tokenem — Re-registrace odregistrovaného nebo revokovaného agenta byla rovnou odmítnuta, takže vyměněný host se nemohl vrátit ani s jednorázovým tokenem vydaným přes reregister. Re-enrollment vyřazeného agenta je nyní povolen pouze účelově vydaným náhradním tokenem — rozlišeným novým diskriminátorem purpose na deployment tokenech — zatímco zastaralé deployment tokeny ani recovery tokeny jej stále nemohou vzkřísit; při úspěchu se vyčistí markery vyřazení agenta a jednorázový token se spotřebuje.
Vzdálená odinstalace selže čistě a hlásí selhání spuštění runneru — Vzdálená odinstalace nyní předem odmítne host bez podporovaného správce balíčků (apt-get/rpm) jako nepodporovaný, místo aby hlásila úspěch po best-effort úklidu, zatímco balíček zůstal nainstalovaný. Pokud se odpojený odinstalační runner nepodaří spustit, agent nyní toto terminální selhání nahlásí zpět přes health kanál — a smíří již přijatou operaci — místo pouhého lokálního zalogování.
Rotace keytab selže bezpečně (fail-closed) při chybě dotazu na stav agenta — Chyba databáze při zjišťování stavu agenta u keytab cíle již není považována za „neaktivní“ (což tiše přeskočilo nasazení, ale rotaci hlásilo jako dokončenou). Rotace nyní při chybě dotazu selže bezpečně a přeskočí pouze potvrzeně neaktivního agenta.
Potvrzení zálohy rotace omezeno na stav recovery_required — POST /rotation/backups/{id}/acknowledge nyní přepíná pouze zálohu, která je skutečně ve stavu recovery_required, a vrací 404 pro neznámé id a 409 pro jakýkoli jiný stav životního cyklu, místo tichého přepsání zálohy v libovolném stavu.
Import Terraform mazevault_deployment obnoví organizaci — Read resource deploymentu nyní znovu naplní organization_id ze serveru, takže importovaný deployment lze zničit; dříve delete volání posílalo prázdnou organizaci a bylo odmítnuto s 400.
Zákaznický Helm chart používá Redis místo tichého přechodu na paměťovou cache — Zákaznický Helm chart měl ve výchozím stavu externalRedis.connectionQuery: abortConnect=false, což je volba StackExchange.Redis (.NET), kterou Redis klient Go backendu odmítá (redis: unexpected option). Backend proto přecházel na paměťovou cache, stav gatewaye nemohl používat Redis a OCSP responder při startu padal do restartovací smyčky. Výchozí hodnota je nyní prázdná a chart odmítne vyrenderovat, pokud connectionQuery obsahuje abortConnect — zákazníci, kteří ho mají ve vlastních values, ho musí odstranit. Backend ani OCSP responder navíc při selhání parsování nebo připojení k Redisu už nelogují heslo: URL v chybách připojení jsou redigovány a chyby parsování URL už neopakují původní URL.
Poznámka u certifikátu odmítnuta pod zobrazeným limitem 256 znaků — Uložení Poznámky (Note) u certifikátu selhávalo i u textu výrazně kratšího než inzerovaných 256 znaků, pokud obsahoval ne-ASCII znaky (například českou diakritiku), a detail certifikátu neposkytl žádnou zpětnou vazbu. Backend vynucoval limit v UTF-8 bajtech, zatímco počítadlo v UI, validátor požadavku i sloupec VARCHAR(256) počítají znaky — dvoubajtový znak jako ř tak spotřeboval dvě jednotky kvóty (u běžného českého textu byl efektivní strop ≈240 znaků). Stejná bajtová kontrola se týkala i tagů certifikátu (64) a dokumentační URL (500). Všechny tři limity jsou nyní na každé vrstvě vynucovány v Unicode znacích, editor poznámky počítá a ořezává po code pointech (emoji se počítá jako jeden znak) a plných 256 znaků lze uložit bez ohledu na písmo. Sekce Tagy / Dokumentace / Poznámka navíc již nepolyká chyby API: validační chyby i chyby oprávnění se zobrazují přímo u pole, editor ponechá rozepsaný text otevřený k opravě a probíhající uložení nelze odeslat dvakrát. Import certifikátu nyní aplikuje stejnou normalizaci tagů (ořez mezer, deduplikace, limity 64 znaků / 50 tagů) jako editor v detailu. Tělo požadavku PUT /certificates/{id} (UpdateCertificateRequest) je nyní popsáno v OpenAPI specifikaci. Změna schématu není potřeba.
Spravované tokeny nešlo v Orchestrator módu uložit do Azure Key Vault — Vytvoření nebo obnova spravovaného tokenu (POST /tokens, POST /tokens/{id}/renew) v Orchestrator módu selhávalo s 500 failed to offload token value to external provider, pokud byl cílem offloadu Azure Key Vault. Obecná offload cesta pojmenovala každou hodnotu bez certifikačních metadat mazevault-keys/key-<unix-timestamp> — cestový identifikátor navržený pro HashiCorp Vault, který Key Vault odmítá, protože názvy secretů smí obsahovat jen [0-9a-zA-Z-] (400 BadParameter: Method PUT does not allow operation 'key-…'). Stejný identifikátor používaly keytaby a privátní klíče importované přes discovery (mazevault-keys/<cn>-<serial>, s tečkami z CN), takže i tyto offloady na Azure selhávaly. Identifikátor se nyní generuje podle providera: Key Vault dostane plochý, čitelný a kolizím odolný název (mazevault-token-<název-tokenu>-<id>, mazevault-keytab-<principal>-<id>, mazevault-<cn>-<serial>), který se validuje proti kontraktu Key Vaultu ještě před odesláním požadavku; HashiCorp Vault a AWS Secrets Manager zachovávají historické uspořádání mazevault-keys/… beze změny. Samotná hodnota tokenu se nikdy nemění — je base64 kódována pro přenos přesně jako dřív a vrací se byte-po-bytu (pokryto testem s shell metaznaky, bílými znaky i Unicode). Tvrdý limit Key Vaultu na jeden secret (25 600 bajtů zakódovaného payloadu, ≈19 200 raw bajtů) se nyní kontroluje předem a hlásí jako 400 s přesným limitem a velikostí odeslané hodnoty místo obecné 500 z Azure; explicitní název secretu porušující vzor Key Vaultu je rovněž odmítnut jako 400, nikoli tiše přepsán. Společně bylo opraveno několik latentních vad ve stejné cestě: token service předávala tenanta pod špatným metadata klíčem (org_id místo organization_id), takže se offload integrace vybírala napříč celým systémem — první povolená secret-manager integrace jakékoli organizace — a reveal / delete tokenu řešily integraci bez jakéhokoli tenant scope; výběr integrace je nyní scopovaný projekt → organizace a nikdy se nerozšíří na vault jiného tenanta (explicitně zvolené integration_id, které chybí nebo je vypnuté, je odmítnuto místo nahrazení jiným); obnova tokenu mazala předchozí externí hodnotu dřív, než byla zapsána nová, takže neúspěšný offload nechal token bez hodnoty — pořadí je nyní zapsat → persistovat → odstranit starou, neúspěšná obnova ponechá předchozí hodnotu netknutou a neúspěšný insert metadat odstraní právě odloženou hodnotu; uložená Azure reference s verzí by při aktualizaci vytvořila nový secret pojmenovaný GUIDem verze — holý název secretu se nyní extrahuje správně; asynchronní worker pro offload secretů dotazoval neexistující sloupec is_active na project_integrations (skutečný příznak je enabled); custody události tokenů a keytabů nyní odkazují na vlastnící záznam, typ klíče a jednajícího uživatele místo náhodného UUID; a sériové číslo certifikátu kratší než osm znaků už nezpůsobí panic generátoru názvů. Není potřeba databázová migrace, změna API ani konfigurace.
Provisioning přes SCIM vytvořil nejvýše jednoho uživatele nebo skupinu — Vytvoření uživatele nebo skupiny přes SCIM (POST /api/v1/auth/scim/{providerID}/Users a /Groups) uložilo identitu bez id, takže první dostala id ze samých nul a každá další selhala s 500 (external_identities_pkey). Uživatel bez externalId (ve SCIM nepovinného a Okta ho neposílá) byl navíc považován za předchozího a odpovídal 500 user already exists. Identity nyní dostávají vygenerované id a uživatel bez externalId se identifikuje podle userName.
Provisioning přes SCIM odpovídá na duplicitního uživatele 409 a na neznámého uživatele či skupinu 404 — Vytvoření SCIM uživatele, kterého poskytovatel už má (POST /api/v1/auth/scim/{providerID}/Users), odpovídalo 500 user already exists a úprava neznámého uživatele (PUT .../Users/{id}) nebo patch neznámé skupiny (PATCH .../Groups/{id}) odpovídaly 500 record not found. Nyní odpovídají 409, 404 User not found a 404 Group not found, jak SCIM klienti očekávají a jak už odpovídaly čtecí cesty.
Export do Terraformu vrací 404 a 400 pro neznámé a nevalidní id — GET /api/v1/terraform/export/project/{id} a .../organization/{id} vracely HTTP 500 pro id, které nepatří žádnému projektu ani organizaci, nebo není UUID. Nově vracejí 404 (project not found, organization not found) a 400 (Invalid Project UUID, Invalid Organization UUID).
Název skupiny integrací musí být v projektu jedinečný (409) — POST /api/v1/projects/{id}/integration-groups a PUT /api/v1/integration-groups/{id} odpovídaly HTTP 500 s chybou databáze, když projekt už skupinu s tímto názvem má. Nyní odpovídají 409 an integration group with this name already exists in the project.
Výpis skupin integrací odpovídá 404 pro neexistující projekt — GET /api/v1/projects/{id}/integration-groups odpovídal 200 s prázdným seznamem pro projekt, který neexistuje. Nyní odpovídá 404 project not found.
Název skupiny integrací delší než 255 znaků odpovídá 400 — POST /api/v1/projects/{id}/integration-groups a PUT /api/v1/integration-groups/{id} odpovídaly HTTP 500 s chybou databáze pro název, který sloupec nepojme. Nyní odpovídají 400 name must be at most 255 characters.
Vytvoření skupiny integrací odpovídá 404 pro neexistující projekt — POST /api/v1/projects/{id}/integration-groups odpovídal HTTP 500 s chybou cizího klíče z databáze, když projekt neexistuje. Nyní odpovídá 404 project not found.
Skupinu integrací lze uložit bez mapování — POST /api/v1/projects/{id}/integration-groups a PUT /api/v1/integration-groups/{id} odpovídaly HTTP 500, když tělo neobsahovalo mappings (sloupec nepřijímá null). Skupina bez mapování se nyní uloží s prázdným seznamem a aktualizace bez mappings mapování vymaže.
Chyby zjišťování v Azure už nevracejí interní text chyby — Selhání GET /api/v1/azure/keyvaults/discover nebo POST /api/v1/azure/keyvaults/check-access (například u uživatele, který není přihlášen přes Entra ID) posílalo interní příčinu v details a routes pro SQL servery Azure a souhrn oprávnění posílaly text neúspěšného volání Azure s kódem 502. Selhání nyní vrací pevnou zprávu a příčinu ponechává v logu serveru. Selhání vyhledání projektu nebo politiky viditelnosti v databázi u GET /api/v1/azure/app-registrations a /azure/subscriptions/{subscriptionId}/keyvaults vracelo 400 s textem databáze; nyní vrací 500 PROJECT_LOOKUP_FAILED nebo VISIBILITY_POLICY_FAILED bez něj.
Vytvoření a úprava integrace organizace odpovídají 400 pro odmítnutou URL — POST /api/v1/organizations/{id}/integrations a PUT /api/v1/organizations/integrations/{integrationId} odpovídaly 500 Internal server error, když kontrola interních adres odmítla URL (například http://127.0.0.1/…). Nyní odpovídají 400 s důvodem (invalid integration config: field "url": …) a nic neuloží.
Náhled rozsahu Entra funguje s maskovanými tajemstvími uložené integrace — Protože tajemství projektové integrace se vracejí jako ********, náhled rozsahu Entra v režimu úprav průvodce integrací posílal masku jako client secret a seznam aplikací nenačetl, dokud uživatel tajemství nezadal znovu. POST /api/v1/entra/projects/{id}/scope-preview přijímá volitelné integration_id uložené integrace Entra ID (stejný projekt): tajná pole poslaná jako ******** nebo vynechaná se vezmou z ní, pokud se její pole koncového bodu (tenant_id, client_id a ostatní pole koncového bodu) nezměnila; změněný koncový bod vyžaduje znovu zadaná tajemství (400 invalid integration config), stejně jako integrace jiného projektu. Uložená integrace se posuzuje s entra:read ve vlastním prostředí a projektu (403, 404 pro neznámou). Bez integration_id se nic nemění.
Vytvoření projektové integrace a navázání agenta vracejí 4xx pro opravitelný vstup — POST /api/v1/projects/{id}/integrations odpovídal 500 na tělo nesprávného tvaru, chybné id projektu a název, který prostředí už používá; nyní odpovídá 400 s chybou vazby, 400 Invalid Project UUID a 409 se zprávou o duplicitním názvu; konfigurace Entra ID, kterou její autentizace na pozadí nemůže použít (například background_auth_method client_secret bez client_secret), vrací 400 s touto zprávou, stejně jako úprava. POST /api/v1/projects/{id}/integrations/agents odpovídal 500 na neplatné environment, neznámého agenta a agenta, kterého projekt už má navázaného; nyní odpovídá 400, 404 Agent not found a 409.
Úprava integrace projektu a cesty relací vracejí 400 pro vstup, který může volající opravit — PUT /api/v1/projects/integrations/{integrationId} vracel 500, když nové konfiguraci integrace Entra ID chybělo, co potřebuje její autentizace na pozadí (například client_secret pro client_secret); nyní vrací 400 s touto zprávou. Cesty databázových relací (…/sessions, …/sessions/terminate, …/sessions/drain) vracejí pro integraci jiného typu 400 integration is not a database integration místo 500.
Test připojení on-behalf-of bez jednotného přihlášení Entra ID už nekončí 500 — POST /api/v1/projects/{id}/integrations/test-connection s autentizací on-behalf-of na serveru bez služby jednotného přihlášení Entra ID požadavek shodil (500). Nyní vrací 200 se success: false a OBO authentication is configured but Entra SSO service is not available, stejně jako test uložené integrace.
Smazání integrace projektu archivuje osiřelá tajemství až po smazání — DELETE /api/v1/projects/integrations/{integrationId}?archive_orphans=true archivoval tajemství, která přišla o poslední integraci, uvnitř databázové transakce mazání: každá archivace čekala na druhé databázové spojení, zatímco transakce jedno držela, a archivace zůstaly i tehdy, když mazání poté selhalo. Tajemství se nyní archivují až po potvrzení smazání a neúspěšné smazání nic nearchivuje.
Úprava a smazání integrace organizace odpovídají 404 pro neznámou integraci — PUT /api/v1/organizations/integrations/{integrationId} odpovídal 500 a DELETE odpovídal 204 (a zapsal auditní záznam DELETE_ORG_INTEGRATION) pro id, které neoznačuje žádnou integraci. Oba nyní odpovídají 404 integration not found a nic neauditují.
Patch SCIM skupiny aplikuje operace s velkými písmeny a odmítá, co nelze provést — PATCH /api/v1/auth/scim/{providerID}/Groups/{id} porovnával název operace s rozlišením velikosti písmen, takže Add a Remove, které posílá Entra ID, nic neměnily, a člen bez value shodil úpravu, což se spolklo a odpovědělo 204 bez provedené změny. Názvy operací jsou nyní bez rozlišení velikosti písmen (RFC 7644) a patch s členem bez id uživatele, add bez hodnoty nebo operací jinou než add a remove (například replace) odpovídá 400 ve SCIM tvaru chyby (scimType invalidValue nebo invalidSyntax) a nic nemění.
Schválení a zamítnutí žádostí o heslo se auditují — Schválení nebo zamítnutí žádosti agenta o heslo ke keystoru (POST /api/v1/admin/password-requests/{id}/approve a /reject) nezapisovalo žádný auditní záznam. Nyní zaznamenají PASSWORD_REQUEST_APPROVED a PASSWORD_REQUEST_REJECTED (entita PASSWORD_REQUEST, id žádosti) s uživatelem a IP adresou; záznamy nikdy neobsahují heslo.
Žádost o heslo lze schválit nebo zamítnout jen jednou — POST /api/v1/admin/password-requests/{id}/approve a /reject odpovídaly 200 i pro neexistující žádost a dovolily znovu vyřídit už schválenou nebo zamítnutou žádost (zamítnutá šla změnit na schválenou, schválené šlo přepsat heslo). Nově vrací 404 pro neznámou žádost a 409 pro žádost, která už není čekající; kontrola stavu je součástí samotné aktualizace, takže dvě souběžná vyřízení nemohou uspět obě. Odmítnuté volání se do auditu nezapisuje.
Neexistující tajemství vrací 404 místo 500 — Úprava tajemství (PUT /api/v1/secrets/{id}), výpis jeho verzí, návrat k jiné verzi (neexistující tajemství nebo verze) a archivace, obnova či trvalé smazání vracely 500, když tajemství už neexistovalo (například smazané v jiné záložce prohlížeče); obnova neexistujícího tajemství dokonce vracela 200 a zapsala auditní záznam RESTORE_SECRET. Nyní vrací 404 a obnova neexistujícího tajemství nezapisuje žádný auditní záznam.
Klíč tajemství lze znovu vytvořit po archivaci nebo smazání tajemství — Vytvoření tajemství (POST /api/v1/secrets/) s klíčem tajemství, které bylo archivováno nebo smazáno, selhávalo s 500 Failed to create secret: unikátní index idx_secrets_unique_key_env_version zahrnoval i archivované a smazané řádky, zatímco kontrola při vytvoření posuzuje jen aktivní. Migrace 000212 omezuje index na aktivní řádky (nearchivované, nesmazané). Obnova archivovaného tajemství, jehož klíč byl mezitím vytvořen znovu, nyní vrací 409 místo databázové chyby.
Kopírování tajemství se audituje — Zkopírování tajemství do jiného prostředí (POST /api/v1/secrets/{id}/copy) nezapisovalo žádný auditní záznam. Nyní se zapisuje COPY_SECRET (entita SECRET, id nového tajemství, v detailech id zdroje a cílové prostředí) s uživatelem a IP adresou; záznam nikdy neobsahuje hodnotu.
Obnova a trvalé smazání odmítnou tajemství, které není archivované — POST /api/v1/secrets/{id}/restore a DELETE /api/v1/secrets/{id}/permanent jednaly nad libovolným tajemstvím: zastaralá záložka Archiv (tajemství bylo mezitím obnoveno nebo nikdy nebylo archivováno) mohla trvale smazat aktivní tajemství a obnova aktivního tajemství zapsala nepravdivý auditní záznam RESTORE_SECRET. Obě nyní vrací 409 secret is not archived, nic nemění a nezapisují auditní záznam.
Obnova a trvalé smazání odmítnou projekt, který není archivovaný, a obnova uživatele, který není smazaný — POST /api/v1/projects/{id}/restore a DELETE /api/v1/projects/{id}/permanent jednaly nad libovolným projektem: zastaralá záložka Archiv (projekt byl mezitím obnoven nebo nikdy nebyl archivován) mohla trvale smazat aktivní projekt včetně všech jeho tajemství a obnova aktivního projektu zapsala nepravdivý auditní záznam RESTORE_PROJECT. POST /api/v1/archived/users/{id}/restore se choval stejně pro uživatele, který není smazaný (RESTORE_USER). Všechna tři volání nyní vrací 409 (project is not archived, user is not deleted), nic nemění a nezapisují auditní záznam.
Trvalé smazání se nemůže předběhnout s obnovou — Trvalé smazání projektu, uživatele nebo tajemství nyní zamkne řádek a před smazáním ověří, že je stále archivovaný (nebo smazaný), takže po obnově dokončené ve stejném okamžiku už nemůže následovat nevratné smazání nyní aktivní položky (smazání vrátí 409); obnova uživatele je jediná podmíněná úprava, takže dvě obnovy už neuspějí obě a nezapíší se dvakrát. Stejnou kontrolu používá i retenční úklid prošlých projektů a tajemství.
Schvalování a přiřazení rolí vrací při překlepu 404 a 400 místo 500 s textem databáze — Vytvoření schvalovací politiky nebo žádosti pro neexistující projekt (POST /api/v1/projects/{id}/approval-policies, …/approval-requests) vracelo 500 s chybou cizího klíče z PostgreSQL; úprava neexistující politiky (PUT /api/v1/projects/approval-policies/{policyId}) vracela 500 record not found; přiřazení role neexistujícímu uživateli, neexistující role nebo s neplatným prostředím v rozsahu (POST /api/v1/rbac/users/{id}/roles) vracelo 500 Internal server error. Na to narazí Go SDK, CLI a Terraform provider při překlepu. Nyní vrací 404 Project not found, 404 Policy not found, 404 user not found / 404 role not found a 400 invalid environment scope … a text databáze se do odpovědi nedostane.
Nastavení prostředí neexistujícího projektu vrací 404 — GET /api/v1/projects/{id}/environment-settings pro neexistující projekt vracelo 500 LIST_FAILED; nyní vrací 404 Project not found.
Uložení nastavení neexistujícího projektu a žádost o schválení s neexistující politikou vrací 404 — PUT /api/v1/projects/{id}/settings pro neexistující projekt vracelo 500 a POST /api/v1/projects/{id}/approval-requests s neexistujícím policy_id vracelo 500 (chyba cizího klíče). Nyní vrací 404 Project not found a 404 Policy not found.
Chyby serveru u projektů, schvalování, poskytovatelů identity, SAML, archivu a žádostí o heslo už neukazují interní text — Selhání volání databáze nebo SAML poskytovatel s neplatnou SSO URL vracely 500 s původním textem chyby (hláška PostgreSQL, record not found, chyba parsování URL) v těle odpovědi, i na veřejných SAML cestách pro metadata a přihlášení. Text se nyní zapisuje jen do logu serveru a tělo je Internal server error; seznam nastavení prostředí si ponechává kód LIST_FAILED a zprávu bez details.
Žádné nepravdivé auditní záznamy u volání, která nic nezměnila — PATCH Universal Auth bez čeho měnit už nezapisuje UPDATE_UNIVERSAL_AUTH, odebrání klientského tajemství, které už odebráno je (stále 204), už nezapisuje druhý REVOKE_CLIENT_SECRET a ponechává čas prvního odebrání a smazání neexistujícího id poskytovatele identity (stále 204) už nezapisuje DELETE_IDENTITY_PROVIDER.
Import, stahování z Azure Key Vault, kopie a řešení konfliktů synchronizace ignorují archivovaná tajemství — Klíč může existovat současně jako archivované i jako aktivní tajemství (migrace 000212). Import do projektu, stahování z Azure Key Vault, kontrola „již existuje“ při kopírování a řešení konfliktu synchronizace hledaly tajemství podle projektu, klíče a prostředí bez vyloučení archivovaných řádků, takže import nebo stažení mohly přepsat archivované tajemství a aktivní ponechat beze změny, kopii mohlo zablokovat archivované tajemství a konflikt synchronizace se mohl vyřešit na špatném tajemství. Nyní berou v úvahu jen aktivní tajemství.
Návrat k verzi a kopie tajemství v Orchestrator Mode vrací 409 s důvodem — Návrat tajemství k dřívější verzi (POST /api/v1/secrets/{id}/rollback, dialog historie) nebo jeho zkopírování do jiného prostředí (/copy) v Orchestrator Mode vracely 500 Failed to rollback secret / Failed to copy secret a skrývaly, že operace tam neexistuje (hodnota je v externím poskytovateli). Nyní vrací 409 s textem rollback is not supported in Orchestrator Mode / copying secrets is not supported in Orchestrator Mode.
Vytvoření tajemství s neplatným prostředím nebo neexistujícím projektem vrací 400/404 místo 500 — POST /api/v1/secrets/ vracel 500 Failed to create secret pro identifikátor prostředí, který platforma nepřijímá (rezervovaný jako default či all, kratší než 2 nebo delší než 32 znaků, nebo neodpovídající [A-Za-z][A-Za-z0-9_-]), a pro neexistující project_id. Na to narážel Terraform provider (mazevault_secret.environment), CLI i Go SDK při překlepu. Nyní vrací 400 s důvodem (invalid environment "x": environment slug is shorter than 2 characters) a 404 Project not found.
Neexistující tajemství vrací 404 v synchronizačních endpointech — Vynucená synchronizace (POST /api/v1/secrets/{id}/force-sync, /environments/{env}/force-sync), stav synchronizace (GET /api/v1/secrets/{id}/sync-status), offload synchronizace (POST /api/v1/secrets/{id}/sync) a stav offloadu (GET /api/v1/secrets/{id}/offload-status) vracely 500, když tajemství už neexistovalo nebo bylo archivováno (například smazané v jiné záložce prohlížeče). Nyní vrací 404.
Vynucená synchronizace pro neplatné prostředí vrací 400 — POST /api/v1/secrets/{id}/environments/{env}/force-sync vracelo 500, když env bylo rezervované nebo neplatný identifikátor prostředí. Nyní vrací 400 s textem chyby.
Synchronizační endpointy tajemství neposílají interní text chyby — Při databázové chybě vynucená synchronizace (POST /api/v1/secrets/{id}/force-sync, /environments/{env}/force-sync), stav synchronizace (GET /api/v1/secrets/{id}/sync-status), log synchronizace (GET /api/v1/secrets/{id}/sync-logs) a detekce driftu (POST /api/v1/secrets/drift/detect) vkládaly původní chybu (názvy tabulek, SQL stav) do těla odpovědi. Nyní vrací 500 s obecnou zprávou; příčina se pouze zapisuje do logu.
Synchronizace tajemství a detekce driftu se auditují — Vynucená synchronizace jednoho prostředí (POST /api/v1/secrets/{id}/environments/{env}/force-sync), offload synchronizace tajemství (POST /api/v1/secrets/{id}/sync) a detekce driftu (POST /api/v1/secrets/drift/detect) nezapisovaly žádný auditní záznam. Nyní zapisují FORCE_SYNC_SECRET_ENVIRONMENT, SYNC_SECRET a DETECT_SECRET_DRIFT s uživatelem a IP adresou (detekce driftu s rozsahem projektu a počty výsledků); záznam nikdy neobsahuje hodnotu tajemství. Odmítnutá volání nezapisují nic.
Požadavek agenta na token na /oauth/token byl odmítnut s 403 — POST /oauth/token (endpoint client credentials popsaný v API příručce a používaný agentem) odpovídal 403 CSRF token mismatch na každý požadavek bez hlavičky Authorization nebo dvojice XSRF cookie a hlavičky z prohlížeče, kterou strojoví klienti neposílají, takže agent nastavený s OAuth klientem nemohl získat token. Kontrola CSRF nyní tento endpoint vyjímá stejně jako /api/v1/auth/token a /api/v1/auth/universal-auth/login: ověřuje se tajným klíčem klienta v těle požadavku, ne cookie.
Změna důvěryhodných IP adres Universal Auth poškodila konfiguraci — PATCH /api/v1/auth/universal-auth/identities/{id} s clientSecretTrustedIps nebo accessTokenTrustedIps skončil pro dvě a více adres chybou 500 a pro jedinou adresu ji uložil jako JSON objekt místo seznamu, po čemž už konfiguraci nešlo načíst: její čtení, změna, vytvoření, výpis nebo zneplatnění klientských tajných klíčů i přihlášení přes Universal Auth odpovídaly 500. Adresy se nyní ukládají jako seznam pro libovolný počet adres (prázdný seznam nedůvěřuje žádné adrese, takže každé přihlášení je odmítnuto s 401 Invalid credentials; pro povolení libovolné adresy pošlete 0.0.0.0/0) a databázová migrace (000213) převede konfigurace poškozené starou změnou zpět na seznamy. PATCH pro identitu bez Universal Auth nyní odpovídá 404 místo 500.
Přihlášení přes SRP odpovídá 400 na neplatný veřejný klíč klienta — POST /api/v1/auth/srp/init odpovídal 500 failed to create SRP server, když byl veřejný klíč klienta A roven 0 modulo prvočíslo skupiny N (například 0, N nebo 2N) nebo z něj vycházel nulový parametr míchání. SRP knihovna takový klíč už odmítala (klíč relace by nezávisel na hesle); route jej nyní hlásí jako 400 invalid public key A místo interní chyby.
Neexistující skupiny konzistence, varování a projekty vrací 404 — Čtení (GET /api/v1/consistency-groups/{id}), úprava (PUT /api/v1/consistency-groups/{id}) a kontrola (POST /api/v1/consistency-groups/{id}/check) skupiny konzistence, která už neexistovala, a vytvoření skupiny v neexistujícím projektu (POST /api/v1/projects/{id}/consistency-groups) vracely 500. Vyřešení neexistujícího varování (POST /api/v1/consistency-warnings/{id}/resolve) vracelo 200, aniž by cokoli změnilo. Nyní vrací 404.
Vyřešení varování konzistence funguje — POST /api/v1/consistency-warnings/{id}/resolve vždy vracelo 500: zapisovalo řešitele, který se z požadavku nikdy nečetl, a databáze to odmítla. Varování se nyní označí jako vyřešené přihlášeným uživatelem, včetně poznámky.
Duplicitní název skupiny konzistence vrací 409 — Vytvoření (POST /api/v1/projects/{id}/consistency-groups) nebo přejmenování (PUT /api/v1/consistency-groups/{id}) skupiny konzistence na název, který projekt už používá, vracelo 500 s databázovou chybou. Nyní vrací 409 se srozumitelnou zprávou.
Název skupiny konzistence je po jejím smazání opět volný — Vytvoření skupiny konzistence (POST /api/v1/projects/{id}/consistency-groups) pod názvem smazané skupiny selhávalo, protože unikátní index názvu zahrnoval i smazané skupiny. Rozbíjelo to nahrazení mazevault_consistency_group v Terraformu. Migrace 000214 omezuje index jen na existující skupiny; dvě existující skupiny projektu stále nemohou mít stejný název.
Endpointy konzistence neposílají interní text chyby — Při databázové chybě vkládaly endpointy skupin a varování konzistence (/api/v1/projects/{id}/consistency/*, /api/v1/consistency-groups, /api/v1/consistency-warnings) původní chybu (názvy tabulek, SQL stav) do těla odpovědi. Nyní vrací 500 s obecnou zprávou; příčina se pouze zapisuje do logu.
Vytvoření a smazání skupiny konzistence se auditují — Vytvoření skupiny konzistence (POST /api/v1/projects/{id}/consistency-groups) a její smazání (DELETE /api/v1/consistency-groups/{id}) nezapisovaly žádný auditní záznam, na rozdíl od úpravy. Nyní zapisují consistency_group_created (s projektem) a consistency_group_deleted s uživatelem a IP adresou. Odmítnutá volání a smazání už neexistující skupiny nezapisují nic.
Seznam archivovaných secretů neposílá interní text chyby — Při databázové chybě vkládal GET /api/v1/archived/secrets původní chybu (názvy tabulek, SQL stav) do těla odpovědi. Nyní vrací 500 s obecnou zprávou; příčina se pouze zapisuje do logu.
Hashe historie hesel neopouštějí backend — Odpovědi se secrety (seznam, aktualizace, kopie, archiv) už neobsahují pole password_history_hashes. Obsahovalo hashe dřívějších hodnot secretů a v praxi bylo prázdné; nic je nečte, takže klienti se nemusí upravovat.
Secret endpointy v2 odpovídají na neznámý a duplicitní vstup kódem 4xx — POST /api/v2/secrets vracel 500 pro název (blind index), který v prostředí už existuje, pro neplatné prostředí a pro neznámý projekt; nyní vrací 409, 400 (se zprávou) a 404. PUT /api/v2/secrets/{id} vrací 404 pro neznámý nebo archivovaný secret a GET /api/v2/projects/{id}/secrets a /secrets/matrix vrací 404 pro neznámý projekt (dříve vše 500). Secret, který POST /api/v2/secrets/migrate nedokáže migrovat, se hlásí pevným textem (secret not found, migration failed, ...) místo původní databázové chyby a archivovaný secret se už nemigruje.
Migrace secretů na zero-knowledge se auditují — POST /api/v2/secrets/migrate přepisoval zašifrovaný název a hodnotu secretů bez auditního záznamu. Každý migrovaný secret nyní zapisuje MIGRATE_SECRET_V2 s uživatelem, IP adresou a prvními 8 znaky blind indexu; žádný šifrovaný text ani nonce se neauditují.
Přístupový log už nezapisuje blind index — GET /api/v2/secrets?project_id=…&blind_index=… zapisoval při každém vyhledání podle názvu celý blind index (HMAC názvu secretu) do pole query přístupového logu. Hodnota se nyní loguje jako [REDACTED]; samotné vyhledání se nemění.
Porovnání secretů kontroluje oprávnění ke čtení obou prostředí — POST /api/v2/secrets/compare (podle blind indexu i podle klíče) vyžadoval jen secret:read v prostředí požadavku, takže uživatel mohl zjistit, které secrety a v jakých verzích existují v prostředích, která číst nesmí. Nyní vyžaduje secret:read na source_env i target_env, jinak vrací 403 insufficient permissions for environment, stejně jako ostatní čtecí routy v2.
Projekt může mít v jednom prostředí více zero-knowledge secretů — Unikátní index klíčů secretů pokrýval i prázdný klíč zero-knowledge (v2) secretu, takže projekt a prostředí mohly obsahovat jediný v2 secret: vytvoření druhého přes POST /api/v2/secrets vracelo 500. Index nyní pokrývá jen secrety s klíčem (migrace 000215, idempotentní); opakovaný blind index se nadále odmítá kódem 409.
Archivace, obnovení, smazání a zrušení odvolání certifikátu ve špatném stavu vrací 409 nebo 404 — POST /api/v1/certificates/{id}/archive pro už archivovaný certifikát vracelo 200 a zapisovalo další auditní záznam; POST …/restore pro certifikát, který není archivovaný (neaktuální seznam Archiv), vracelo 200 a zapisovalo auditní záznam; DELETE …/permanent nearchivovaného certifikátu ho nenávratně smazalo; a neznámý certifikát vracel 500 s databázovým textem (u obnovení 200). Nyní vracejí 409 (certificate is already archived, certificate is not archived) nebo 404 a nic nemění, odmítnuté volání nezapisuje auditní záznam; trvalé smazání zamyká řádek a znovu ho ověřuje uvnitř transakce. POST …/unrevoke vrací 404 pro neznámý certifikát a 409 pro certifikát, který není odvolaný nebo nebyl pozastaven (kód důvodu 6), místo 400; odvolání a zrušení odvolání certifikát zamykají, takže dvě současná volání nemohou obě uspět.
Certifikátové endpointy neposílají interní text chyby — Při databázové chybě vkládala archivace, obnovení, trvalé smazání, odvolání a zrušení odvolání certifikátu (/api/v1/certificates/{id}/…) a výpis jeho rotačních cílů původní chybu (názvy tabulek, SQL stav) do těla odpovědi a čtení certifikátu nebo jeho stavu vracelo 404 při jakékoli chybě. Nyní vrací 500 s obecnou zprávou (jen chybějící certifikát je 404); příčina se pouze zapisuje do logu.
Odvolání certifikátu, který nevydala žádná CA, vrací 409 místo 500 — POST /api/v1/certificates/{id}/revoke (i POST /api/v1/projects/{id}/certificates/{certId}/revoke, který nyní odvolává stejným kódem) vracel 500 se zprávou certificate has no associated CA pro certifikát bez CA systému MazeVault, například importovaný, který tlačítko Odvolat nabízí. Nyní vrací 409 se stejnou zprávou.
Úprava certifikátu v rozporu s pravidlem šablony vrací 409 nebo 400 místo 500 — PUT /api/v1/certificates/{id} vracelo 500 Failed to update certificate, když se upravovala nastavení automatické obnovy certifikátu, jehož nastavení obnovy řídí šablona, a když šablona patřila jiné organizaci než projekt certifikátu. Nyní vrací 409 (cannot manually edit renewal settings when certificate is governed by a template) a 400 (template belongs to a different organization than the target project, nebo renewal_key_policy, který služba odmítne) s důvodem.
Zrušení pozastavení certifikátu se auditují — POST /api/v1/certificates/{id}/unrevoke vracel certifikát do stavu aktivní bez auditního záznamu, na rozdíl od odvolání. Nyní zapisuje certificate.unrevoked (entita certificate) s uživatelem a IP adresou. Odmítnutá volání nezapisují nic.
Projektový endpoint odvolání odvolá certifikát, který pojmenovává — POST /api/v1/projects/{id}/certificates/{certId}/revoke bral id projektu jako id certifikátu, takže každé odvolání ze záložky Certifikáty projektu skončilo 404 a nic se neodvolalo. Nyní odvolá certifikát certId v projektu z cesty; certifikát jiného projektu vrací 404 (Certificate not found in this project), již odvolaný certifikát nebo certifikát, který nevydala žádná CA systému MazeVault, vrací 409.
Projektové PKI endpointy už neposílají interní text chyb — Při selhání databáze nebo správce tajemství vypsání CA, CSR a certifikátů projektu, vytvoření projektové CA (/api/v1/projects/{id}/ca, /csr, /certificates) a vypsání tajemství integrace (/api/v1/projects/{id}/integrations/{integrationId}/secrets) vkládaly do odpovědi původní chybu (názvy tabulek, SQL stav, text poskytovatele). Nyní vrací 500 s obecnou zprávou ve stejném tvaru; příčina se pouze zapíše do logu.
Schválení nebo zamítnutí projektového CSR, který zmizel nebo už byl rozhodnut, vrací 404 nebo 409; přiřazení chybějící šablony vrací 404 — POST /api/v1/projects/{id}/csr/{csrId}/approve a …/reject vracely 500 pro CSR, který neexistoval, patřil jinému projektu nebo ho mezitím rozhodl či archivoval někdo jiný (neaktuální seznam v záložce Schvalování CSR). Neznámý nebo cizí CSR nyní vrací 404, CSR, který už není ve stavu čekající, 409 s jeho stavem; požadavek se obsazuje podmíněnou aktualizací (schválení) nebo se zamkne a znovu přečte (zamítnutí), takže ho nemohou zpracovat dva schvalovatelé zároveň. POST /api/v1/projects/{id}/templates/{template_id} vracel 500 pro šablonu nebo projekt, které už neexistují, i pro šablonu jiné organizace; nyní vrací 404 a 400 (template and project belong to different organizations).
Projektové CSR endpointy fungují s API tokenem — Požadavek s API tokenem nenese do projektových CSR endpointů organizaci, takže POST /api/v1/projects/{id}/csr/{csrId}/approve a …/reject hledaly požadavky bez organizace a žádný nenašly, a CSR odeslaný tokenem (POST /api/v1/projects/{id}/csr) se uložil bez organizace, takže ho nemohl nikdo schválit. Endpointy nyní používají organizaci, kterou požadavku přidělí kontrola oprávnění (u tokenu výchozí organizaci, stejně jako u relace).
Změny CSR a inicializace CA projektu se auditují — Odeslání (POST /api/v1/projects/{id}/csr), schválení a zamítnutí projektového CSR a inicializace projektové CA (POST /api/v1/projects/{id}/ca/initialize) nezapisovaly žádný auditní záznam (inicializace CA zapisovala jen dva ladicí záznamy o typu projektu, jeden z nich ještě před ověřením požadavku; oba jsou odstraněny). Nyní zapisují SUBMIT_PROJECT_CSR, APPROVE_PROJECT_CSR, REJECT_PROJECT_CSR a INITIALIZE_PROJECT_CA s jednajícím uživatelem, požadavkem nebo CA a IP adresou; odmítnuté volání nezapíše nic.
Inicializace CA neznámého projektu vrací 404 — POST /api/v1/projects/{id}/ca/initialize vracel 500 (Failed to get project), když projekt neexistuje nebo je archivovaný. Nyní vrací 404 (Project not found).
Obnovy čekající na ověření domény lze uložit — Kontrola stavu fronty obnov povolovala devět stavů, ale kód nastavuje i ověření domény (pending_dcv), čekání na schválení ADCS (awaiting_adcs_approval), čekání na navazující krok CA (awaiting_ca_followup) a manual_review; zápis kteréhokoli z nich selhal a objednávka se tak nikdy nedostala do panelu DCV na záložce Certifikáty projektu. Migrace 000217 (idempotentní) povoluje všech třináct stavů, které kód používá.
Akce fronty obnov ve špatném stavu vrací 409 nebo 404 — Zrušení dokončené nebo zrušené obnovy (POST /api/v1/renewal-queue/{id}/cancel) vracelo 200 a přepsalo stav, zrušení neznámé položky vracelo 200, schválení položky, která nečeká, nebo neznámé vracelo 500, obnovení běhu neznámé položky vracelo 409 bez důvodu, panel DCV vracel pro neznámou položku 200 s prázdným seznamem a pro špatný stav, chybějící objednávku nebo certifikát bez účtu CA 400 s interním textem (ID položky a certifikátu, record not found) a obnova či historie neznámého certifikátu vracela 500 nebo prázdný seznam. Nyní vrací 404 pro neznámou položku nebo certifikát a 409 s krátkou zprávou pro špatný stav a nic nemění; selhání volání samotné CA zůstává 400 s textem CA, jakákoli jiná chyba je obecná 500.
Souběžná volání obnovy se nemohou provést dvakrát — Obnova běhu neúspěšné obnovy nejprve přečetla položku, potom nasadila a teprve poté ji označila jako nasazovanou, takže dvě současná volání POST /api/v1/renewal-queue/{id}/resume mohla obě nasadit na cíle a dvě současná volání POST /api/v1/certificates/{id}/renew mohla obě nenajít otevřenou obnovu a zařadit dvě (dvě placené objednávky u CA). Obnova běhu nyní položku nárokuje podmíněným updatem dřív, než se cokoli nasadí (druhé volání vrací 409), a obnova se zařazuje pod zámkem řádku certifikátu.
Endpointy DCV a backfill obnov neposílají interní text chyby — Při chybě databáze vracely GET /api/v1/renewal-queue/{id}/dcv a POST …/dcv/retry 500 s původní chybou a POST /api/v1/admin/certificates/backfill a …/backfill-aia ji vkládaly do message odpovědi. Nyní vrací obecnou 500; příčina se pouze zapisuje do logu.
Backfilly certifikátů se auditují — POST /api/v1/admin/certificates/backfill a …/backfill-aia přepisují metadata certifikátů všech projektů, ale nezapisovaly auditní záznam. Nyní zapisují záznamy BACKFILL_CERTIFICATES a BACKFILL_CERTIFICATE_AIA s uživatelem, adresou a počtem aktualizovaných certifikátů; odmítnuté volání nezapisuje nic.
Neplatné ID organizace je ve frontě obnov 400 — GET /api/v1/renewal-queue/?organization_id=… vracel 500 pro hodnotu, která není UUID. Nyní vrací 400 (Invalid organization ID).
Čísla CRL se nikdy nevydají dvakrát — Obnovení CRL přečetlo poslední číslo CRL autority a to další zapsalo až později, takže dvě současná obnovení (požadavek a plánovač, nebo dva požadavky) mohla vydat CRL se stejným číslem, které klienti nedokážou seřadit. Číslo se teď zabere jedním podmíněným updatem ještě před podpisem CRL; číslo, jehož CRL se pak nepodepíše, zůstane nevyužité, což RFC 5280 dovoluje.
Obnovení CRL se audituje a pro neznámou CA vrací 404 — POST /api/v1/ca/{id}/crl/regenerate odpovídal 500 s interním textem služby (failed to get CA: NOT_FOUND: …) pro neznámou CA i pro CRL, které se nepodařilo podepsat, a nezapisoval audit. Neznámá CA nyní vrací 404 CA not found (403 pro volajícího s rolí omezenou na organizaci, viz „Routy certifikačních autorit zůstávají v organizaci volajícího“), selhání podpisu obecné 500 Internal server error (příčina jde jen do logu) a každé obnovení se zaznamenává jako REGENERATE_CRL s uživatelem, CA a druhem a číslem CRL; odmítnuté volání nezaznamená nic.
HSM a externí konfigurace CA vrací 404 pro neznámou CA a projeví se okamžitě — POST /api/v1/ca/{id}/hsm, …/external/configure, …/external/test a …/external/templates/sync odpovídaly 500 pro neexistující CA (externí konfigurace se pro ni dokonce pokusila uložit řádek). Nyní odpovídají 404 CA not found (403 pro volajícího s rolí omezenou na organizaci, viz „Routy certifikačních autorit zůstávají v organizaci volajícího“). Nastavení HSM mění jedním updatem jen sloupce HSM dané CA místo zápisu celého dříve přečteného řádku, takže už nemůže vrátit souběžnou změnu (například adresu OCSP), a zahodí cachovaného providera CA, takže se nová konfigurace použije při podpisu hned, ne až po vypršení cache. Externí konfigurace a aktualizace CA jsou jedna transakce; při selhání aktualizace nezůstane napůl zapsaná konfigurace. Konfigurace externí CA dříve nikdy neuspěla (odpovídala 500 Failed to configure external CA, protože zapisovala sloupce CA, které neexistují); nyní zapíše poskytovatele do type, provider_type a provider_status CA a odpoví 200.
Změny konfigurace CA se auditují — Nastavení HSM nebo externí CA u autority a synchronizace jejích šablon (POST /api/v1/ca/{id}/hsm, …/external/configure, …/external/templates/sync) nezapisovaly audit. Nyní se zaznamenávají jako CONFIGURE_CA_HSM, CONFIGURE_CA_EXTERNAL a SYNC_CA_TEMPLATES s uživatelem, CA a typem poskytovatele (nebo počtem šablon), nikdy s PINem, přihlašovacími údaji ani jinými hodnotami konfigurace; odmítnuté volání nezaznamená nic.
Test připojení k externí CA vyžaduje ca:admin a audituje se — POST /api/v1/ca/{id}/external/test kontaktuje externí CA a zapisuje její stav, ale stačilo mu ca:read. Nyní vyžaduje ca:admin jako konfigurace externí CA (volající jen s čtením dostane 403) a zapisuje do auditu TEST_CA_EXTERNAL s uživatelem a CA.
Formulář HSM u CA nastaví použitelné HSM — POST /api/v1/ca/{id}/hsm přijímal jen plochou konfiguraci HSM, takže tělo {provider, config} z konzole vrátilo 200, ale uložilo zapnuté HSM bez poskytovatele; CA pak přestala fungovat (selhalo vydání CRL i podepisování) a nešlo to vrátit. Route nyní přijímá tělo z konzole (poskytovatel se stane typem, config poli; plochý tvar s type funguje dál) a pro prázdný či nepodporovaný typ poskytovatele (pkcs11, aws_kms, azure_kv, gcp_kms, trezor, ledger) odpoví 400 dřív, než cokoli změní.
Inicializace kořenové CA odmítá velikosti klíče a platnosti, které nemohou fungovat — POST /api/v1/ca/initialize a POST /api/v1/projects/{id}/ca/initialize odpovídaly 500 pro RSA klíč menší než 2048 bitů, přijímaly zápornou nebo absurdní platnost a generovaly klíč libovolné velikosti i minuty (velikost milion bitů). Nyní odpovídají 400 s důvodem pro velikost RSA klíče mimo 2048–8192 a pro valid_years mimo 1–100, ještě než se cokoli vygeneruje nebo uloží.
Inicializace kořenové CA se audituje — Vytvoření kořenové CA přes POST /api/v1/ca/initialize nezapisovalo audit. Nyní se zaznamenává jako INITIALIZE_CA s uživatelem, novou CA a jejím názvem (nikdy s klíčovým materiálem); odmítnuté volání nezaznamená nic.
Routy šablon certifikátů vrací 404 pro neznámou šablonu a 400 pro špatnou organizaci — GET, PUT a DELETE /api/v1/certificate-templates/{id} odpovídaly 500 pro šablonu, která neexistuje (nebo byla smazána), a DELETE ničeho odpovídal 204 a zapsal audit DELETE_TEMPLATE. Nyní odpovídají 404 Template not found a audituje se jen smazání, které něco smazalo. Chybně zadané organization_id u seznamu a vytvoření odpovídá 400 Invalid organization ID místo 500. Úprava šablony zamkne její řádek pro čtení a zápis, takže dvě souběžné úpravy už nepřepíšou pole jedna druhé.
Šablona certifikátu přijímá jen CA účet a produkt své organizace — POST /api/v1/certificate-templates/ a PUT …/{id} ukládaly ca_account_id a ca_product_id z těla bez kontroly, takže šablonu šlo nastavit k vydávání z CA účtu jiné organizace (nebo neexistujícího), který pak objednával certifikáty s účtem této organizace. Účet musí patřit organizaci šablony a produkt tomuto účtu (nebo bez účtu některému účtu organizace); jinak routa odpoví 400 a nic neuloží. Stejná kontrola platí, když šablonu certifikátu vytváří nebo mění šablona projektu (viz „Šablony projektů zůstávají ve své organizaci“).
Souběžné obnovy už nevyčerpají databázová spojení — Zahájení obnovy (tlačítko Obnovit, POST /api/v1/certificates/{id}/renew a obnovy rotační služby) zamkne certifikát a pak četlo politiku opakovaného použití klíče přes sdílený pool spojení, takže každá obnova držela jedno spojení a čekala na druhé. Při dostatečném počtu obnov najednou (zhruba tolik, kolik má pool spojení, ve výchozím stavu 25) držela každé spojení obnova čekající na další a celý backend přestal odpovídat. Politika se nyní čte na spojení vlastní transakce obnovy.
Zamítnutí projektového CSR nedrží databázi, dokud se maže klíč — POST /api/v1/projects/{id}/csr/{csrId}/reject zamykal žádost v transakci a uvnitř mazal její externě uložený klíč přes služby, které používají sdílený pool spojení, takže zamítnutí drželo jedno spojení a čekalo na druhé. Dostatek takových volání najednou pool vyčerpal. Žádost se teď zabere (stav rejected) v krátké transakci a klíč se maže až potom; žádost schválená mezitím už o klíč přijít nemůže a když se klíč smazat nepodaří, zamítnutí se vrátí zpět (CSR zůstane pending a volání odpoví 500).
Schválení a spuštění obnovy se auditují bez ohledu na běh — POST /api/v1/renewal-queue/{id}/approve a POST /api/v1/certificates/{id}/renew zapisovaly audit (APPROVE_RENEWAL, TRIGGER_RENEWAL) jen při úspěchu celé obnovy, ačkoli schválení je uloženo a položka fronty existuje dřív, než obnova běží. Schválení nebo spuštění, jejichž běh selhal, čeká na CA (běžný výsledek u DigiCert a SSLMarket) nebo přišlo o položku ve prospěch jiného workeru, nezanechalo stopu. Obojí se nyní audituje ihned po uložení, s výsledkem běhu (dokončen, čeká na CA nebo operátora, selhal, převzal jiný worker); odmítnuté schválení a spuštění, které jen našlo už běžící obnovu, nic nemění a už se neauditují (druhé se dřív auditovalo).
Rotační cesty certifikátu už nevracejí databázové chyby a selhání čtení už není 404 — Rotační konfigurace, historie, předběžné kontroly a cíle nasazení certifikátu při selhání databáze nebo rotační služby vracely v těle 500 text chyby a čtení způsobilosti, běhu a cíle vracelo jakoukoli chybu databáze jako 404 „not found“. Nyní vracejí pevné tělo „Internal server error“ a 404 ponechávají pro záznamy, které neexistují.
Změny cílů nasazení a rotační konfigurace certifikátu se auditují — Vytvoření, úprava a smazání cíle nasazení (POST, PUT, DELETE /api/v1/certificates/{id}/targets…) a úprava rotační konfigurace (PUT /api/v1/certificates/{id}/rotation/config) nezapisovaly žádný auditní záznam. Každá změna nyní zapíše záznam (certificate_rotation_target_created, …_updated, …_deleted, certificate_rotation_config_updated) s názvy změněných polí, nikdy s jejich hodnotami, a s výsledkem outcome=success, případně outcome=failed, když změna na serveru selhala.
Neplatné id certifikátu na cestách cílů certifikátu je 400 — GET, PUT, DELETE /api/v1/certificates/{id}/targets/{targetId}, GET …/status a POST …/sync id certifikátu v cestě nebraly v úvahu, takže neplatné id se zpracovalo jako platné (200 nebo 204). Nyní vracejí 400 „Invalid certificate ID“, stejně jako ostatní cesty certifikátu.
Přiřazení nalezených SSH klíčů působí jen na klíče organizace volajícího — POST /api/v1/ssh/discovery/{id}/assign, /ignore, /bulk/assign a /bulk/ignore působily na libovolný nalezený klíč. Nově působí na klíč jen tehdy, když agent, který jej našel, patří do organizace volajícího (klíč agenta bez organizace vyžaduje oprávnění neomezené na organizaci); jiný klíč, stejně jako neznámý, odpovídá 404 Key not found a hromadný požadavek, který takový klíč obsahuje, nezmění žádný ze svých klíčů. Projekt jiné organizace nebo neznámý projekt či uživatel v přiřazení odpovídá 404. Seznam, statistiky a návrhy shody zůstávají globální.
SSH klíče uživatele se čtou jen v rámci organizace volajícího — GET /api/v1/rbac/users/{id}/ssh-keys vypisovala všechny nalezené klíče přiřazené uživateli, včetně klíčů nalezených agenty jiných organizací. Nově vypisuje jen klíče nalezené agenty organizace volajícího (klíče agentů bez organizace jen pro oprávnění neomezené na organizaci).
Rotační konfigurace SSH klíčů se posuzují přes jejich klíčový pár — GET/POST /api/v1/ssh/rotation, GET /api/v1/ssh/rotation/key/{key_pair_id}, PUT a DELETE /api/v1/ssh/rotation/{id} zobrazovaly a měnily rotační konfiguraci libovolného klíčového páru. Konfigurace je nově dostupná jen přes svůj klíčový pár: projekt klíčového páru musí patřit do organizace volajícího (nebo do organizace, kde volající oprávnění má, jako role neomezená na organizaci) a konfiguraci vidí jen vlastník klíčového páru nebo správce SSH; seznam obsahuje jen takové konfigurace a jakákoli jiná odpovídá jako neexistující (404). Změna nebo smazání neexistující konfigurace odpovídá 404 (dvojí smazání dříve vracelo 204) a vytvoření konfigurace pro neznámý klíčový pár odpovídá 404 key pair not found (dříve 500).
Chyby SSH discovery a SSH rotace už neobsahují text databáze — Selhání za /api/v1/ssh/discovery, /api/v1/ssh/rotation a /api/v1/rbac/users/{id}/ssh-keys odpovídalo 500 s textem chyby ovladače; nově odpovídá {"error":"Internal server error"} a příčina se jen zaloguje. Vytvoření rotační konfigurace pro klíčový pár, který ji už má, odpovídá 409 (dříve 500). Rotační konfigurace klíčového páru, kterou nelze načíst (GET /api/v1/ssh/rotation/key/{key_pair_id}), odpovídá 500, ne 404 rotation config not found, takže selhání databáze se nezobrazí jako „zatím bez konfigurace“.
Chyby agentních SSH cest už neobsahují text databáze — Selhání za dotazováním a potvrzováním autorizovaných klíčů agentem (/api/v1/agents/me/authorized-keys/..., /agent/{agent_id}/authorized-keys/...), za jeho hlášením SSH discovery (POST /api/v1/agents/me/ssh-discovery) a za POST /agent/discover vracelo 500 s textem chyby ovladače; nově vrací {"error":"Internal server error"} a příčina se jen zaloguje.
Nasazení klíčů agentem, hlášení SSH discovery a discovery agentů se auditují i s výsledkem — Potvrzení nasazení autorizovaného klíče agentem (SSH_AUTHORIZED_KEY_DEPLOYMENT_CONFIRMED, výsledek deployed nebo failed), jeho hlášení SSH discovery (SSH_DISCOVERY_REPORT_SUBMITTED, počet klíčů) a POST /agent/discover (AGENT_DISCOVERED, výsledek created, updated, nebo refused u odregistrovaného či revokovaného agenta) nově zapisují auditní záznam.
Přiřazení nalezených SSH klíčů a změny rotačních konfigurací SSH se auditují s výsledkem — Přiřazení nebo ignorování nalezených SSH klíčů (jednotlivě i hromadně) a vytvoření, změna či smazání rotační konfigurace SSH nově zapisují auditní záznam s výsledkem (assigned, ignored, created, updated, deleted) a záznam také pro zamítnutý nebo selhaný požadavek (refused, failed). Změna rotační konfigurace zapisuje jen interval a stav a přijímá jen stav active nebo paused (jinak 400); přiřazení klíče už nepřepisuje pole, která obnovuje hlášení agenta.
Výměna dat keytabu a uložení politiky šifer keytabů opět fungují — PUT /api/v1/keytabs/{id} s novými keytab_data a PUT /api/v1/keytabs/cipher-policy vracely 500 pro každý platný požadavek (typy šifrování a seznamy šifer se do databáze zapisovaly ve tvaru, který odmítla), takže nešlo keytab vyměnit ani změnit politiku šifer organizace. Obě cesty nově uspějí: výměna uloží keytab, jeho typy šifrování a soulad, politika se uloží a rozhoduje o souladu, který uloží obnovení.
Chyby keytabů už nenesou text databáze a opravitelný vstup vrací 4xx — Selhání za /api/v1/keytabs (výpis, čtení, úprava, mazání, historie, soulad, politika šifer, objevené keytaby, přehled) vracelo 500 s textem databázové chyby ve zprávě a databázová chyba při čtení keytabu vracela 404. Nově vracejí 500 Internal server error (příčina se jen zaloguje) a databázová chyba se už nebere jako neznámý keytab. Vstup, který volající může opravit, je 400/404 se svou zprávou místo 500: náhradní keytab_data, která není keytab (400), neznámý enforcement_mode politiky šifer (400, odmítnutá politika se už neukládá) a stažení keytabu, který neukládá soubor keytabu, například vzniklého z objevení (404).
Změny keytabů se auditují i s výsledkem a úprava keytabu přijímá jen známé stavy — Úprava a smazání keytabu, uložení politiky šifer a obnovení souladu šifer (PUT a DELETE /api/v1/keytabs/{id}, PUT /api/v1/keytabs/cipher-policy, POST /api/v1/keytabs/refresh-compliance) nezapisovaly žádný záznam auditu. Nově zapisují záznamy keytab.update, keytab.delete, keytab.cipher_policy_update a keytab.compliance_refresh, které končí výsledkem, a auditují se i odmítnutá nebo selhaná úprava, smazání, stažení, import a import objeveného keytabu (outcome: refused nebo outcome: failed); žádný záznam neobsahuje hodnotu keytabu. Úprava keytabu se status, který není active, inactive, expired, revoked ani discovered, vrací 400 (dříve uložila libovolný text). Výměna souboru keytabu už nečte politiku šifer, dokud její transakce drží databázové spojení, takže souběžné výměny nevyčerpají pool spojení, a dvě souběžné úpravy jednoho keytabu archivují jeho verze jednu po druhé.
Routy spravovaných tokenů fungují pro API tokeny bez ?organization_id= — Routy spravovaných tokenů (/api/v1/tokens) četly organizaci jen ze session nebo JWT, takže API token (Terraform provider, CLI, automatizace) vracel pro každý požadavek 400 organization context required, pokud neposlal ?organization_id=. Nově jednají v organizaci API tokenu stejně jako session; parametr dotazu má přednost a oprávnění se dál posuzuje.
Spravované tokeny se posuzují ve své organizaci a projektu — Vytvoření spravovaného tokenu s project_id, který neexistuje, vracelo 500 a projekt jiné organizace se přijal. Nový token nově vyžaduje projekt organizace volajícího (jinak 404) a oprávnění v něm a každá routa tokenu podle id (čtení, zobrazení hodnoty, úprava, obnovení, smazání a cíle) posuzuje oprávnění v projektu tokenu, nebo v jeho organizaci, když projekt nemá, takže role omezená na jednu organizaci je odmítnuta (403) u tokenu vázaného na projekt jiné organizace. Výpisy dál obsahují jen organizaci volajícího.
Zobrazení spravovaného tokenu se nikdy neukládá do cache — GET /api/v1/tokens/{id}/value (záměrné zobrazení uložené hodnoty tokenu, vyžaduje token:admin) nově vrací Cache-Control: no-store, takže prohlížeč ani proxy hodnotu neuchová. Zobrazení se dál auditují (záznam nikdy neobsahuje hodnotu) a žádná jiná routa tokenů ani routa servisních identit kromě vytvoření (které jednou vrátí nové client secret) nenese uloženou hodnotu ani tajemství.
Chyby servisních identit už nenesou text databáze a přejmenování tokenu se ověřuje — Selhání za /api/v1/service-identities vracelo 500 s textem databázové chyby ve zprávě; nově vrací 500 Internal server error (příčina se jen zaloguje) a databázová chyba při čtení identity se už nebere jako neznámá identita. Úprava neznámé identity vracela 500 record not found a smazání neznámé 204; obojí je nově 404. Přejmenování spravovaného tokenu na prázdný název je 400 a na název jiného tokenu stejné organizace a projektu 409, stejně jako při vytvoření (dříve se uložilo).
Cíl spravovaného tokenu musí používat integraci organizace tokenu — Přidání cíle nasazení ke spravovanému tokenu přijalo libovolné id integrace. Integrace nového cíle musí nově existovat a patřit do organizace tokenu (jinak 404) a volající potřebuje oprávnění token:write v projektu, kterému integrace patří (jinak 403). Agenta cíle posuzuje další položka.
Změny spravovaných tokenů a servisních identit se auditují s výsledkem a úpravy přijímají jen známé hodnoty — Odmítnuté nebo selhané úpravy, obnovení, smazání, zobrazení, změny cílů a vytvoření spravovaného tokenu i servisní identity nezapisovaly žádný záznam auditu; nově zapisují záznam, který končí výsledkem (outcome: refused nebo outcome: failed), a záznamy servisních identit končí created, updated nebo deleted; žádný záznam neobsahuje hodnotu tokenu ani tajemství. Úprava spravovaného tokenu se status, který není active, expired ani revoked, vrací 400 (dříve uložila libovolný text) a úprava servisní identity zapisuje jen zobrazované jméno, popis a e-mail vlastníka, takže souběžná rotace tajemství už není přepsána. Smazání tokenu odstraní jeho řádky v jedné transakci dříve, než se smaže jeho přesměrovaná hodnota.
Routy keytabů fungují pro API tokeny bez ?organization_id= — Routy keytabů (/api/v1/keytabs) četly organizaci jen ze session nebo JWT, takže API token vracel pro každý požadavek 400 organization context required, pokud neposlal ?organization_id=. Nově jednají v organizaci API tokenu stejně jako session; parametr dotazu má přednost a oprávnění se dál posuzuje.
Import keytabu musí uvádět projekt organizace volajícího — Import keytabu nebo objeveného keytabu s project_id jiné organizace či neexistujícím se uložil bez kontroly (a záznam auditu uváděl cizí projekt). Projekt nově musí existovat v organizaci volajícího (jinak 404) a volající potřebuje keytab:write na něm (jinak 403); pro odmítnutý projekt se nic neimportuje.
Spravovaný token se doručuje jen agentovi svého rozsahu — Cíl nasazení spravovaného tokenu mohl uvádět libovolného agenta, takže se hodnota tokenu mohla poslat agentovi jiné organizace nebo projektu, ke kterému token nepatří. Cíl s agentem nově vyžaduje agenta s aktivní integrací projektu tokenu, má-li token projekt, jinak agenta organizace tokenu (jinak 404); agent bez organizace token nikdy nedostane. Doručení kontroluje totéž, takže cíl vytvořený dříve s cizím nebo bezorganizačním agentem selže bez odeslání hodnoty a žádná chyba ani výstup hodnotu tokenu nenese.
Stránka výsledků discovery agenta zobrazuje nalezená data — Stránka Discovery Results agenta (/agents/{id}/discovery) nyní u každého certifikátu zobrazuje subjekt, vydavatele, expiraci, umístění, zdroj a stav Managed z uložených dat discovery. Dřívější stránka četla pole, která API nevrací, takže buňky byly prázdné a každý certifikát se zobrazoval jako „Unmanaged“.
Multi-DC Sync Status zobrazuje zdrojové datacentrum — Sloupec Source DC na stránce Multi-DC Sync Status (/multi-dc) četl pole, které backend neposílá (source_dc místo datacenter_id), a zůstával proto prázdný. Nyní ukazuje datacentrum, které událost vytvořilo.
Historie rotací přihlašovacího údaje Entra ukazuje jen jeho rotace — Tlačítko Rotation History u přihlašovacího údaje aplikace Entra vypisovalo rotace všech přihlašovacích údajů aplikace. Nyní vypíše rotace daného údaje; tlačítko Rotation History u samotné aplikace nadále ukazuje všechny.
Rotační nastavení Entra nelze uložit přes nepřečtenou konfiguraci — Dialog Configure Rotation u přihlašovacího údaje Entra zobrazil výchozí hodnoty, když se uložená konfigurace nepodařila přečíst, a jejich uložení nahradilo uložené akce po rotaci prázdným seznamem. Dialog nyní ukáže chybu s tlačítkem Retry a nejde uložit, dokud se konfigurace nepřečte. Odmítnuté uložení (neplatné nastavení, adresa webhooku, Springu nebo akce po rotaci na loopbacku či link-local adrese) se zobrazí u formuláře se zprávou backendu.

Bezpečnostní a závislostní aktualizace¶

Akce po rotaci tajemství odmítají lokální URL — Akce po rotaci v konfiguraci rotace tajemství (POST /api/v1/rotation/configs, PUT /api/v1/rotation/configs/{id}, PUT /api/v1/secrets/{id}/rotation-config: záložka Rotace tajemství) se ukládaly bez kontroly, přestože MazeVault po rotaci volá jejich url webhooku a API notifikace, actuator_url a endpoints Springu a agent_url, takže držitel secret:rotate mohl přimět server poslat rotovanou hodnotu sám sobě, metadatové službě cloudu nebo jiné link-local adrese. Taková URL (loopback, link-local, nespecifikovaná nebo multicast adresa v jakémkoli zápisu, localhost) se nyní odmítne 400 s názvem pole (například post_actions[0].config.url: URL host "169.254.169.254" is not allowed (internal network)) a nic se neuloží. Privátní rozsahy zůstávají povolené.
Nastavení rotace Entra odmítají lokální URL po rotaci — URL, které MazeVault volá po rotaci přihlašovacího údaje Entra (webhook_urls, spring_endpoints a url, actuator_url, endpoints a agent_url v post_rotation_actions u POST a PUT /api/v1/entra/credentials/{id}/rotation-config), se ukládaly bez kontroly, takže držitel entra:write mohl přimět server poslat nový přihlašovací údaj sám sobě, metadatové službě cloudu nebo jiné link-local adrese. Taková URL (loopback, link-local, nespecifikovaná nebo multicast adresa v jakémkoli zápisu, localhost) se nyní odmítne 400 s názvem pole (například webhook_urls[0]: URL host "169.254.169.254" is not allowed (internal network)) a nic se neuloží. Privátní rozsahy (10.*, 192.168.*) zůstávají povolené.
Akce po rotaci certifikátu odmítají lokální URL — Akce po rotaci v konfiguraci rotace certifikátu (PUT /api/v1/certificates/{id}/rotation/config) nyní procházejí stejnou kontrolou URL jako nastavení rotace tajemství a Entra: url webhooku nebo API notifikace, actuator_url či endpoints Springu nebo agent_url, které míří na samotný server, link-local adresu (metadata cloudu), nespecifikovanou nebo multicastovou adresu v jakémkoli zápisu, vrací 400 s názvem pole (post_rotation_actions[<n>].config.<key>) a nic se neuloží. Privátní rozsahy zůstávají povolené.
Vytvoření připraveného sekundárního údaje Entra už nevrací nové tajemství — POST /api/v1/entra/credentials/{id}/staged-secondary vracel volajícímu hodnotu nového klientského tajemství v otevřeném textu (new_secret), přestože ho MazeVault sám nasazuje do nastavených cílů po rotaci a trasa rotace ho nikdy nevracela. Připravený sekundární údaj a povýšení (POST …/promote-primary) nyní vracejí jen id nového údaje, id klíčů, stav a zprávu; new_secret z obou odpovědí zmizel.
Trasy přihlašovacích údajů Entra se posuzují tam, kam údaj patří — Trasy přihlašovacího údaje Entra (DELETE /api/v1/entra/credentials/{id}, POST …/preflight, POST …/rotate, POST …/dry-run, GET …/rotation-history, GET, POST a PUT …/rotation-config, POST …/staged-secondary, POST …/promote-primary, POST …/verify-secondary), POST /api/v1/entra/sync-conflicts/{id}/resolve a GET /api/v1/entra/subjects/{id} posuzovaly oprávnění jen v prostředí požadavku, takže role omezená na dev mohla v Entra smazat nebo rotovat přihlašovací údaj z prod, změnit jeho konfiguraci rotace nebo povýšit jeho připravený sekundární údaj a role omezená na organizaci mohla pracovat s údaji jiné organizace. Nyní se posuzují v prostředí integrace Entra, ke které údaj (konflikt, subjekt) patří, a v jejím projektu: jinak 403 a nic se nezmění. Role omezená na projekt nyní dosáhne na trasy přihlašovacích údajů aplikací svého projektu; vyřešení konfliktu a čtení subjektu takovou roli dál odmítají. Neznámý přihlašovací údaj vrací 404 Entra credential not found dřív, než se cokoli přečte (dříve různé texty 404, 200 s neúspěšnou kontrolou u suchého běhu, 409 u připraveného sekundárního údaje a povýšení, 500 u PUT …/rotation-config); neznámý konflikt vrací 404 conflict not found (dříve 500).
Bezpečnost: přihlašovací údaj Entra bez své integrace vrací 404 — Přihlašovací údaj, jehož registrace aplikace neměla řádek integrace, se posuzoval v prostředí požadavku, takže na něm mohla jednat role omezená na toto prostředí. Jeho trasy (/api/v1/entra/credentials/{id}/… a POST /api/v1/rotation/resources/entra_credential/{id}/trigger) nyní vracejí 404 (fail closed), dokud se aplikace neopraví.
Konflikty synchronizace integrace Entra se posuzují tam, kam integrace patří — GET /api/v1/entra/{integrationId}/sync-conflicts posuzovalo entra:read jen v prostředí požadavku, takže role omezená na dev mohla vypsat konflikty synchronizace integrace v prod svého projektu. Nyní se posuzuje v prostředí a projektu integrace: jinak 403. Neznámá integrace vrací 404 integration not found (dříve 200 []).
Seznam integrací napříč projekty ukazuje jen to, co volající smí číst — GET /api/v1/integrations (výběr integrace na dashboardu Entra) vracel integrace všech projektů všech organizací ve všech prostředích každému, kdo měl integration:read. Nyní vrací jen integrace projektů organizace požadavku v prostředích a projektech, kde má volající integration:read: role omezená na dev vidí integrace dev a správce organizace nikdy nevidí integrace jiné organizace. Konfigurace integrací se nevracela a nevrací.
Trasy aplikací Entra se posuzují tam, kam integrace patří — Trasy registrací aplikací integrace Entra (GET a POST /api/v1/entra/{integrationId}/apps, POST …/sync, GET …/subjects) a aplikace (GET, PUT a DELETE /api/v1/entra/apps/{id}, GET a POST …/credentials, POST …/mark-managed, GET …/rotation-history) posuzovaly entra:read / entra:write jen v prostředí požadavku, takže role omezená na dev mohla číst, měnit nebo mazat aplikace integrace v prod a role omezená na organizaci aplikace jiné organizace. Nyní se posuzují v prostředí a projektu integrace (aplikace v prostředí a projektu své integrace): jinak 403 a nic se nezmění. Neznámá integrace vrací 404 integration not found (dříve 500 u seznamu, vytvoření a synchronizace a 200 [] u subjektů). Role omezená na projekt nyní dosáhne na trasy Entra integrací a aplikací svého projektu, včetně GET a PUT /api/v1/entra/{integrationId}/scope, které jí vracely 403.
Gateway pracuje jen se svými úlohami — Každá ověřená gateway mohla vypsat a převzít úlohy jiné gateway, když poslala její id (GET /api/v1/gateway/tasks?gateway_id=, GET /api/v1/gateways/{id}/tasks, gateway_id v POST /api/v1/gateway/tasks/{id}/claim), a mohla změnit libovolnou úlohu podle jejího id (PATCH /api/v1/gateway/tasks/{id}); úlohy nesou operace s Key Vaultem a Entrou. gateway_id jiné než id ověřené gateway (X-Gateway-ID) nyní vrací 403 {"error": "gateway_id does not match the authenticated gateway"} a změna úlohy jiné gateway nebo neexistující úlohy vrací 404 {"error": "task not found"} (neexistující úloha dříve vracela 500). Gateway posílají své vlastní id, takže se jich změna netýká.
Zkušební běh rotace už nic nerotuje — Zkušební běh certifikátu (tlačítko Dry Run na záložce rotace certifikátu, POST /certificates/{id}/rotation/trigger nebo POST /rotation/resources/certificate_renewal/{id}/trigger s "dry_run": true) parametr dry_run ignoroval a provedl skutečnou obnovu certifikátu, která u předplatitelské CA mohla založit placenou objednávku, a konzole pak hlásila, že se nic nezměnilo. Spouštěč zdroje dělal totéž u všech ostatních druhů: zkušební běh cíle nasazení certifikátu ho synchronizoval, u přihlašovacího údaje Entra nebo servisní identity vytvořil nový tajný klíč, u systémového klíče nebo páru klíčů SSH ho rotoval. Zkušební běh těchto druhů nyní nic nespouští: vrací 200 s preflightem zdroje jen pro čtení (RotationPreflightResponse, stejné vyhodnocení jako preflight publikační brány), posuzuje se ve vlastním rozsahu zdroje se stejným oprávněním jako spouštěč a audituje se s outcome=dry run. Zkušební běh cíle nasazení, který nelze synchronizovat ručně, vrací 400 stejně jako jeho spouštěč. Spouštěč certifikátu dokumentuje obě odpovědi (běh, nebo preflight zkušebního běhu). Zkušební běh tajného klíče dál spouští své kroky rotace v režimu pouhé kontroly, několik z nich ale dry_run ignorovalo a zapisovalo: krok tajného klíče uložil náhledové heslo ***dry-run-preview*** jako novou hodnotu tajného klíče (v režimu orchestrátoru zvýšil jeho verzi), kroky odeslání do Key Vaultu, synchronizace agenta a synchronizace proměnné CI/CD tuto hodnotu odeslaly do propojených cílů a stažení z Key Vaultu přepsalo místní tajný klíč novější hodnotou z trezoru. Každý z těchto kroků nyní při zkušebním běhu svůj zápis vynechá. Zkušební běh tajného klíče navíc ukládal svůj workflow zkušebního běhu do sdílené konfigurace rotace tajného klíče, kterou si pak běh na pozadí znovu načetl: zkušební běh a skutečná rotace spuštěné současně si mohly prohodit kroky (zkušební běh provedl skutečnou rotaci, nebo skutečná rotace potichu nic neudělala). Zkušební běh tajného klíče si nyní svůj workflow drží sám a konfiguraci rotace nikdy nezapisuje; už nevytváří zálohu, při selhání nic neobnovuje ani nekompenzuje, nespouští akce po rotaci, neaktualizuje stav synchronizace integrací, neposouvá plán rotace ani neuzavírá incident selhání rotace a během skutečné rotace už neselže s „rotation already in progress“. Jeho běh je v metadatech označen dry_run, stejně jako zařazený záznam běhu, kterým spouštěč odpovídá 202, takže obnovení selhaného už neposouvá plán ani neuzavírá incident.
Integrace agenta se upravuje jen tam, kde existuje — PUT /api/v1/agent-integrations/{id} posuzovalo id integrace, jako by to bylo id projektu, který žádný projekt není, takže role project:write omezená na organizaci požadavku upravovala integrace agentů všech ostatních organizací a role omezená na dev upravila integraci z prod (nebo ji do prod přesunula) tím, že uvedla dev. Integrace se nyní posuzuje ve vlastním projektu, ve vlastním prostředí a v prostředí, ke kterému ji požadavek váže; role přiřazená jednomu projektu upravuje jen integrace tohoto projektu.
Tajný klíč se propojí jen s integrací vlastního projektu a jeho propojení a cíle se posuzují v jeho rámci — POST /secrets/{id}/links přijímalo integraci libovolného projektu či organizace (porovnávalo se jen prostředí) a hodnotu tajného klíče do ní následně odeslalo, takže uživatel, který smí rotovat jeden tajný klíč, mohl jeho hodnotu poslat do integrace, ke které přístup neměl. Integrace musí patřit projektu tajného klíče (jinak 404). DELETE /secrets/{id}/links/{linkId} smazalo libovolné propojení bez ohledu na tajný klíč v cestě; propojení musí patřit tajnému klíči (jinak 404, i pro neexistující propojení, které dřív vracelo 204). Cíl nasazení, který uvádí integraci jiného projektu (binding_ref nebo config.integration_id), nově vyžaduje také secret:write v tomto projektu.
Rotační konfigurace, propojení a cíle tajného klíče se posuzují v jeho vlastním prostředí a projektu — /secrets/{id}/rotation-config, /links a /rotation/targets (i jejich synchronizace) posuzovaly požadavek v prostředí, které uvedl klient (?environment= nebo hlavička), takže uživatel omezený na dev mohl číst, měnit, propojovat nebo synchronizovat rotaci tajného klíče z prod tím, že uvedl dev. Nyní se posuzují v prostředí a projektu samotného tajného klíče; role přiřazená jednomu projektu funguje na tajných klíčích tohoto projektu a na ostatních je odmítnuta. DELETE /secrets/{id}/links/{linkId} s neplatným id tajného klíče nyní vrací 400 místo smazání propojení.
Neautentizované routy pro registraci agentů jsou odstraněny z API jádra — POST /api/v1/enroll, POST /api/v1/heartbeat a POST /api/v1/key-exchange backendu již neexistují. Registrace nevyžadovala autentizaci a komukoli vracela licenční klíče, zabalené šifrovací klíče a OAuth klienty; výměna klíčů nemohla nikdy uspět. Nevolala je žádná komponenta MazeVault: licencování a POC registrace probíhají přes licenční server (LICENSE_SERVER_URL), který zůstává beze změny.
ACME finalize a revoke-cert již neposílají text CA providera — Když CA provider selhal nebo odmítl podpis či zneplatnění, ACME problem dokument obsahoval text chyby providera. Každá chyba ACME serveru (HTTP 5xx) nyní vrací pevný text Internal server error s typem serverInternal; odpovědi 4xx si ponechávají typ a detail.
Chyby SCEP, OCSP a ACME již neposílají interní text chyby — Selhání operace SCEP, požadavku OCSP nebo volání ACME serveru nyní vrací pevný text Internal server error (stavové kódy a tvar ACME problem dokumentu se nemění); příčina se zapisuje pouze do logu serveru. Dříve mohla odpověď obsahovat text databáze nebo knihovny.
Rotační konfigurace, běhy, zálohy a zdroje se posuzují v prostředí a projektu samotného objektu — Rotační cesty posuzovaly požadavek v prostředí, které uvedl klient (?environment= nebo hlavička), a u konfigurací a záloh v žádném projektu, takže uživatel omezený na dev mohl číst, měnit, mazat nebo předběžně ověřit rotační konfiguraci tajného klíče z prod tím, že uvedl dev, a uživatel s rolí přiřazenou jednomu projektu byl na konfiguracích tohoto projektu odmítnut. Nyní se /rotation/configs/{id} (i /preflight), POST /rotation/configs (tajný klíč v těle), /rotation/executions/{id} (i /resume), /rotation/backups/{id}/reveal|restore|acknowledge a /rotation/resources/{kind}/{id} (i /readiness, /history) posuzují v projektu a prostředí samotného tajného klíče, běhu nebo zdroje. Zobrazení, obnovení a dosud nekontrolované potvrzení zálohy vyžadují secret:read na tajném klíči zálohy v jeho vlastním projektu a prostředí. Seznamy projektu (rotation-configs, rotation-resources) vynechají prostředí, která volající nesmí číst, a /rotation/executions, /rotation/backups a /rotation/resources vypisují jen organizaci požadavku (a čitelná prostředí).
Spuštění rotace se posuzuje v prostředí a projektu rotovaného zdroje — Čtyři cesty spouštějící rotaci (POST /certificates/{id}/rotation/trigger, POST /rotation/resources/{kind}/{id}/trigger, POST /rotation/configs/{id}/trigger, POST /secrets/{id}/rotate) posuzovaly oprávnění v prostředí, které uvedl klient, takže uživatel, který smí spouštět rotace jen v dev, mohl obnovit certifikát prod nebo rotovat tajemství prod odesláním ?environment=dev. Každé spuštění a také GET /rotation/resources/{kind}/{id} s /readiness a /history se nyní posuzuje v rozsahu samotného zdroje: tajemství v prostředí a projektu svého tajemství, obnova certifikátu v prostředí a projektu certifikátu, cíl nasazení v rozsahu svého certifikátu, Entra credential v projektu své registrace aplikace (a v prostředí její integrace); SSH pár klíčů vyžaduje vlastníka nebo ssh:admin; systémový klíč nebo service identity, které nepatří žádnému projektu, vyžadují roli neomezenou na projekt ani organizaci. Role přidělená jednomu projektu nyní může spouštět rotace tajemství a certifikátů tohoto projektu. Neznámý zdroj vrací 404 (neznámé tajemství u /secrets/{id}/rotate a neznámý certifikát u /certificates/{id}/rotation/trigger dříve vracely 500).
Rotace systémového klíče vyžaduje system:admin — POST /rotation/resources/system_key/{id}/trigger směl použít kdokoli s rotation:write, zatímco POST /admin/rotation/rotate vyžaduje system:admin. Nyní vyžaduje také system:admin, neomezené na organizaci ani projekt; bez něj vrací 403. Konzole zobrazuje záložku Systémové klíče jen s system:admin.
Rotační záznamy bez projektu vyžadují roli neomezenou na organizaci — Běhy rotace bez projektu a rotační zdroje bez projektu (systémové klíče, SSH páry klíčů, service identity a tokeny bez projektu) vypisovaly GET /rotation/executions a GET /rotation/resources a podle id je mohla číst jakákoli role, která prošla cestou, včetně administrátora omezeného na jednu (nebo jinou) organizaci. Nyní je vypisuje a čte jen role neomezená na projekt ani organizaci; administrátor organizace vidí záznamy projektů své organizace. Týká se to cest rotace (/rotation/...); samotné cesty service identity pokrývá bod „Service identity vyžadují roli neomezenou na organizaci“.
Export privátního klíče SSH se posuzuje tam, kde pár klíčů leží — POST /api/v1/ssh/keys/{id}/export ověřoval ssh:admin v pevném prostředí dev bez ohledu na projekt a organizaci páru klíčů, takže ssh:admin omezené na jednu organizaci exportovalo privátní klíče párů jiné organizace. Export nově vyžaduje ssh:admin na projektu páru klíčů v prostředí požadavku; pár klíčů bez projektu vyžaduje ssh:admin neomezené na projekt ani organizaci (jinak 403, v auditu dál jako zamítnutí). Neznámý pár klíčů vrací 404 ještě před ověřením oprávnění.
Konflikty rotace a neúspěšná obnovení nesou pevné zprávy — Několik odpovědí 409 cest rotace (obnovení běhu, potvrzení zálohy, spuštění rotace tajemství a certifikátu, rotace systémového klíče) a auditní záznam neúspěšného obnovení opakovaly text vnitřní chyby, který mohl obsahovat id běhů, stavy nebo zabalenou chybu poskytovatele. Nově nesou pevné zprávy, například rotation execution is already completed a rotation backup is not in recovery_required state (už bez aktuálního stavu); obnova certifikátu, která už čeká, vrací renewal is waiting on an external party s kódem RENEWAL_IN_PROGRESS.
Certifikáty bez projektu vyžadují na cestách rotace neomezenou roli — GET /rotation/resources už rolím omezeným na organizaci skrýval rotaci obnovy a nasazení certifikátů bez projektu (importovaných nebo platformních), ale cesty rotačního zdroje podle id, jejich spouštění a /api/v1/certificates/{id}/rotation* a /targets* je takové roli dál obsluhovaly. Tyto cesty rotace nově pro certifikát bez projektu vyžadují roli neomezenou na projekt ani organizaci (jinak 403); samotné cesty certifikátů (zobrazení, export, obnova) se nemění.
Opakované nasazení páru klíčů bez projektu funguje pro neomezené role — PUT /api/v1/ssh/keys/{id}/deploy vracel pro SSH pár klíčů bez projektu 404 všem včetně vlastníka. Takový pár klíčů nově opakovaně nasadí jeho vlastník nebo ssh:admin, jehož ssh:write není omezené na projekt ani organizaci; role omezená na organizaci dostane 403.
Výjimka správce SSH se posuzuje tam, kde pár klíčů leží — Na /api/v1/ssh/keys (generování, import, výpis, opakované nasazení) a /api/v1/ssh/authorized-keys (výpis, nasazení, odvolání, odebrání) se při práci s párem klíčů jiného uživatele ověřovalo ssh:admin v pevném prostředí dev bez ohledu na organizaci a projekt: ssh:admin omezené na dev jednalo jako správce SSH všude včetně prod a omezené na prod nebylo správcem nikde. ssh:admin nově platí v prostředí požadavku na projektu páru klíčů, stejně jako na cestách rotace SSH; pár klíčů bez projektu a výpisy přes všechny vlastníky vyžadují ssh:admin neomezené na projekt ani organizaci (výpis filtrovaný projektem: ssh:admin na tomto projektu). Generování nebo import páru klíčů pro jiného uživatele nově nejdřív ověří projekt, neznámý projekt tedy vrací nejdřív 404.
Administrátorské cesty systémových klíčů vyžadují neomezeného správce systému — GET /api/v1/admin/rotation/keys a POST /api/v1/admin/rotation/rotate přijímaly system:admin omezené na jednu organizaci, zatímco rotace týchž klíčů celé instalace přes /rotation/resources/system_key/{id}/trigger vyžadovala system:admin neomezené na projekt ani organizaci. Obě administrátorské cesty nově vyžadují také toto neomezené system:admin (jinak 403).
Service identity vyžadují roli neomezenou na organizaci — Service identity nepatří žádné organizaci, přesto GET, POST, PUT a DELETE /api/v1/service-identities (i /{id}) dovolily roli omezené na jednu organizaci vypsat, vytvořit, upravit a smazat service identity celé instalace. Tyto cesty nově vyžadují oprávnění service_identity:* z role neomezené na projekt ani organizaci (jinak 403), stejně jako už rotace tajemství service identity.
Odmítnuté čtení rotačního zdroje už nezapisuje do read modelu — GET /api/v1/rotation/resources/{kind}/{id}, /readiness a /history vytvořily nebo obnovily záznam rotačního zdroje dřív, než ověřily volajícího, takže volající bez přístupu (nebo z jiné organizace) přiměl server k zápisu a SSH pár klíčů bez projektu vracel 500 místo 403. Volající se nově ověřuje nejdřív; odmítnuté čtení nic nezapíše a vrací 403, neznámý objekt jako dříve 404.
Preflight rotace čte jen ten, kdo smí číst jeho objekt — GET /api/v1/rotation/preflights/{id} vracel libovolný preflight komukoli s rotation:read v organizaci požadavku, včetně preflightů tajemství a certifikátů jiné organizace a systémových klíčů. Preflight se nově posuzuje stejně jako připravenost objektu, který kontroloval: rotation:read musí platit v prostředí a projektu tohoto objektu (jinak 403), preflight systémového klíče, service identity nebo bez objektu vyžaduje roli neomezenou na projekt ani organizaci a preflight, jehož objekt už neexistuje, vrací 404.
Starší agentní cesty už nevydávají tokeny agentů ani SSH klíče jiných agentů — Kterýkoli přihlášený volající (uživatel bez oprávnění, API token) mohl voláním POST /agent/discover s hostname registrovaného agenta získat platný token tohoto agenta, nebo s novým hostname založit agenta, a přes GET /agent/{agent_id}/authorized-keys/pending a POST /agent/{agent_id}/authorized-keys/{authorized_key_id}/confirm číst a potvrzovat čekající autorizované SSH klíče libovolného agenta. Obě cesty /agent/{agent_id}/... nově obslouží jen aktivního agenta, kterého agent_id jmenuje (kdokoli jiný dostane 403 agent is not registered, včetně neplatného agent_id, dříve 400; neaktivní nebo zrušený agent dostane 403 agent is not active i na vlastní cestě), a POST /agent/discover vyžaduje oprávnění agent:admin neomezené na projekt ani organizaci (jinak 403). Agenti dál používají nezměněné cesty /api/v1/agents/me/authorized-keys/....
Odmítnuté a neexistující exporty soukromého SSH klíče se auditují — Auditní záznam ssh_key.export zanechal jen úspěšný POST /api/v1/ssh/keys/{id}/export. Zamítnutý export, který dojde až do obsluhy (nejde o vlastníka klíče), a export neexistujícího klíče nově zanechá záznam také, s výsledkem (nikdy ne s klíčem). Požadavky, které už kontrola trasy zamítne kódem 403 (chybí ssh:admin), se zde neauditují.
Generování, import, vytvoření s nasazením a podepsání SSH klíčů se posuzuje v organizaci volajícího — project_id v těle POST /api/v1/ssh/keys, /ssh/keys/import, /ssh/keys/create-and-deploy a /ssh/sign se neověřovalo, takže administrátor omezený na jednu organizaci mohl vytvářet klíčové páry a podepisovat certifikáty v projektu jiné organizace. Takový projekt, stejně jako neznámý, nově odpovídá 404; oprávnění navíc musí platit na projektu v prostředí požadavku (403).
SSH klíčové páry pro jiného uživatele vytváří jen SSH administrátor a vytvoření, nasazení a podepsání se zapisují do auditu — POST /api/v1/ssh/keys a POST /api/v1/ssh/keys/import brala vlastníka z user_id v těle, takže kdokoli s ssh:write mohl vytvářet klíčové páry jménem jiného uživatele (a auditní záznam uváděl tohoto uživatele). Nově odpovídají 403, pokud user_id není volající nebo volající nemá ssh:admin, a auditní záznam uvádí volajícího. Vytvoření s nasazením, žádosti o nasazení autorizovaného klíče a neúspěšné opakování nově zapisují auditní záznam s výsledkem.
Opakované nasazení SSH klíče je omezeno na vlastníka klíče nebo SSH administrátora — PUT /api/v1/ssh/keys/{id}/deploy nasadil veřejný klíč kteréhokoli uživatele na agenta každému, kdo měl ssh:write. Nově platí pravidlo ostatních tras klíčových párů: znovu nasadit může vlastník klíčového páru nebo držitel ssh:admin (ostatní dostanou 403) a klíčový pár projektu jiné organizace odpovídá 404 jako neznámý.
Uzavření incidentu se posuzuje v organizaci, projektu a prostředí incidentu a zapisuje se do auditu — POST /api/v1/incidents/{id}/resolve uzavřel incident libovolné organizace každému, kdo měl incident:resolve, na neexistující id odpovídal 200 a nezanechal záznam v auditu. Nově odpovídá 404 pro neznámý incident i pro incident jiné organizace, role omezená na projekt uzavírá jen incidenty tohoto projektu (žádný bez projektu), oprávnění se ověřuje i v prostředí incidentu a každé uzavření se zapisuje do auditního logu s výsledkem. Při chybě se už nevrací text vnitřní chyby.
Rotační problémy: selhání jiné organizace se nevypisují ani nepotvrzují — Seznam rotačních problémů vracel selhané rotace všech organizací a potvrzení selhání fungovalo na řádku libovolné organizace. Seznam nově obsahuje jen selhání organizace volajícího a potvrzení selhání jiné organizace vrací 404, stejně jako u neznámého id. Platformní selhání, která nepatří k žádnému projektu, se vypisují a potvrzují jen pro roli, která není omezena na organizaci.
Cesta k PKCS#11 modulu se načítá přesně tak, jak ji operátor uvedl — Kontrola HSM_PKCS11_MODULES porovnávala lexikálně očištěnou cestu zařízení, ale knihovna se načítala z cesty, jak byla zapsána; operační systém ale rozlišuje .. přes symbolické odkazy, takže /allowed/dir/link/../lib.so kontrolou prošlo a mohlo načíst jiný soubor. module_path, jehož očištěný tvar se liší od zadaného (.., ., zdvojená či koncová lomítka), se nyní odmítne; použijte cestu přesně tak, jak je uvedena v seznamu.
EAB přihlašovací údaje lze zneplatnit jen ve vlastní organizaci a nové vytvářet jen pro její projekty a šablony — DELETE /api/v1/organizations/{id}/acme-credentials/{credId} hledalo údaje jen podle id, takže administrátor jedné organizace mohl zneplatnit ACME EAB údaje jiné organizace (ACME klienti té organizace se pak nemohli zaregistrovat). Údaje se nyní hledají v organizaci z cesty (jinak 404) a zneplatňují podmíněnou aktualizací (druhé zneplatnění vrátí 409, souběžná zneplatní jednou). Vytvoření údajů (POST .../acme-credentials) přijímalo projekt i výchozí šablonu libovolné organizace; oba musí patřit organizaci z cesty (jinak 404).
Nastavení PKI organizace nemůže propojit CA jiné organizace — Uložení organizace s pki_mode: root a pki_root_cn hledalo kořenovou CA podle jména mezi CA všech organizací a propojilo první, kterou nepoužíval žádný živý účet, takže správce organizace mohl uvést jméno CA jiné organizace (jméno CA je vydavatel každého jí vydaného certifikátu) a vydávat z ní a obejít pravidlo ca_authority_id. Nově se hledají jen vlastní CA organizace (včetně smazaných účtů); pokud žádná není, vytvoří se nový kořen.
Cesta k modulu PKCS#11 už nemůže načíst libovolný nativní kód — module_path zařízení HSM typu PKCS#11 je sdílená knihovna, kterou server načítá, a načtení spouští konstruktory knihovny, takže kdokoli, kdo smí zapisovat zařízení HSM (správce organizace, API token), mohl spustit nativní kód v procesu, který drží hlavní klíč. Načítají se jen moduly, které provozovatel uvede v HSM_PKCS11_MODULES, a to na jediném místě načítání (test spojení, kontrola stavu, směrování klíčů, existující zařízení); vytvoření nebo změna zařízení PKCS#11 s jiným modulem vrací 400, stejně jako POST /api/v1/ca/{id}/hsm s poskytovatelem PKCS#11, jehož modul není uveden nebo chybí.
Relace HSM přes PKCS#11 se serializují a zavírají bezpečně — Poskytovatel PKCS#11 sdílel jednu relaci HSM a nezamčenou mapu handlů klíčů mezi souběžnými podpisy, takže paralelní podpisy mohly shodit server (souběžný zápis do mapy) nebo použít relaci poskytovatele, který se právě zavíral. Relaci i mezipaměť nově chrání jeden zámek; operace nad zavřeným poskytovatelem vrátí chybu a nesáhne na uvolněný modul.
Neúspěšná synchronizace CA už neukládá ani nelogguje, co CA řekla — Když synchronizace (tlačítko Synchronizovat, plánovač, synchronizace produktů) selhala, surová chyba poskytovatele — která může nést tělo odpovědi CA, jméno interního hostitele nebo ozvěnu odmítnutého přihlašovacího údaje — se ukládala do validation_error účtu a do úlohy synchronizace, byla čitelná přes trasy účtů a zapisovala se do logu. Nově nesou pevný text s HTTP stavem, kterým CA odpověděla; příčina se loguje bez přihlašovacích údajů a bez těla odpovědi.
CA organizace nelze převzít po smazání jejího účtu — Propojení účtu CA s autoritou (ca_authority_id v přihlašovacích údajích) přijímalo každou CA na úrovni organizace, kterou nepoužívá žádný živý účet jiné organizace, takže poté, co organizace B smazala svůj účet interní CA, mohla organizace A propojit CA organizace B (jejíž id je součástí každého vydaného certifikátu) a vydávat z ní. CA na úrovni organizace musí nově propojovat účet téže organizace a žádný účet jiné organizace, včetně smazaných; CA, kterou žádný účet nepropojuje, se odmítne.
Změna URL účtu CA vyžaduje jeho přihlašovací údaje — Úprava, která změnila base_url (nebo jinou URL, kterou platforma volá s přihlašovacími údaji účtu) bez odeslání přihlašovacích údajů, přeskočila kontrolu spojení a další synchronizace nebo synchronizace produktů pak poslala uložený API klíč na nového hostitele, takže ho mohl získat správce, který ho nikdy neznal. Taková úprava nově vrací 400; pošlete s ní přihlašovací údaje a ověří se proti novému hostiteli.
Tajemství v nastavení účtů CA jsou maskovaná a šifrovaná — Nastavení, která schéma poskytovatele CA označuje jako tajná (přihlašovací údaje poskytovatele DNS pro DNS validaci SSLmarket, EAB HMAC klíč ACME poskytovatelů), se ukládala jako prostý JSON a každá trasa účtů CA je vracela v metadata všem, kdo smějí účty CA číst. Nově se ukládají šifrovaně (hodnoty ENC:; stávající prostý text se zašifruje při příští změně účtu) a zobrazují se jako __MASKED__. Úprava, která pošle zpět masku nebo prázdnou hodnotu, ponechá uložené tajemství, nová hodnota ho nahradí a null ho odstraní, takže úprava účtu v UI ani nasazení přes Terraform je už nepřepíše ani neprozradí.
Import certifikátu se bez organizace odmítne — Import páruje existující certifikát jen mezi certifikáty organizace; požadavek bez organizace se mlčky párovalo s certifikáty libovolné organizace. Nově vrací 403 „organization context is required“, stejně jako adopce.
Zařízení HSM a politiky obnovy se hledají v organizaci z cesty — Trasy zařízení a politik pod /api/v1/organizations/{id}/hsm-devices a /renewal-policies četly, měnily, testovaly nebo mazaly zařízení či politiku jen podle id, bez ohledu na organizaci v cestě, takže správce jedné organizace (nebo kdokoli s oprávněním) mohl zasahovat do zařízení a politik jiné organizace. Nově se hledají v organizaci z cesty: id jiné organizace vrátí 404 a nic nezmění. Úpravy a mazání zamykají řádek, takže souběžné smazání nelze vrátit zpět. Smazání neexistující politiky obnovy nově vrací 404 místo 204 a neplatné id organizace v cestě u get, test a health zařízení vrací 400.
Chyby importu certifikátu ukazují jen chyby vstupu, ať příčina obsahuje jakákoli slova — Routy importu rozhodovaly, zda chybu ukázat, hledáním slov jako „invalid“ nebo „required“ kdekoli v textu, takže selhání uložení klíče, trezoru nebo databáze, jehož zpráva některé z nich obsahovala (například selhání odložení klíče do trezoru nebo neplatná posloupnost bajtů při aktualizaci), vracelo 400 s interním textem, a to při jednotlivém importu i v chybách položek hromadného importu a importu souboru. Chyba se nově ukáže jen tehdy, když začíná jako vlastní chyba vstupu služby importu (neplatný nebo nečitelný certifikát či klíč, nesoulad, duplicita, nepodporovaný formát, špatné heslo, chybějící oprávnění); vše ostatní vrací 500 „Internal server error", u položky „Failed to import certificate", a příčina jde do logu.
Certifikáty vydané ze žádosti vznikají v prostředí žádosti — POST /api/v1/certificates/csr se posuzuje v prostředí volání, ale certifikát vydaný ze žádosti vznikl vždy v prod, takže uživatel omezený na dev mohl získat certifikát v prod přes šablonu, která schválení nevyžaduje. Žádost nově ukládá své prostředí (migrace 000218, stávající žádosti zůstávají v prod) a certifikát ho přebírá, ať se vydá hned, nebo až po schválení (vlastní prostředí schvalovatele nehraje roli). Změna chování: certifikáty požadované přes POST /api/v1/certificates/csr se nově objeví ve zvoleném prostředí a klient, který prostředí neposílá, dostane výchozí prostředí serveru, ne vždy prod. POST /api/v1/projects/{id}/csr přebírá prostředí svého volání stejně; POST /api/v1/gateways/csr přebírá prostředí, ke kterému je gateway vázaná.
Import certifikátu nemůže změnit certifikát jiné organizace — Import certifikátu nebo privátního klíče doplní tělo existujícího certifikátu se stejným otiskem, nebo k němu připojí klíč, ale vyhledávání zasahovalo přes organizace: správce jedné organizace, který importoval veřejný certifikát bez projektu, mohl dokončit záznam jiné organizace nebo převzít jeho klíč. Shoda je nově omezena na organizaci volajícího (certifikáty jejích projektů a certifikáty bez projektu, které nevydal účet CA jiné organizace); certifikát jiné organizace není shoda, import tedy vytvoří vlastní a druhý záznam, jeho projekt i klíč nechá beze změny.
Zamítnutí nebo archivace žádosti o certifikát už nemůže zničit klíč žádosti, která se vydává — Zamítnutí a archivace mazaly externě uložený privátní klíč čekající žádosti (Azure Key Vault, správce tajemství) dříve, než změnily její stav, takže schválení, které přišlo mezitím, přišlo o klíč, zatímco zamítnutí vrátilo 409, a archivace neměla žádnou podmínku na stav. Obě nově žádost nejprve podmíněnou změnou převezmou a klíč smažou až poté (selhání smazání klíče převzetí vrátí). Archivace žádosti, která je schválená, vydává se nebo byla předána CA, nově vrací 409 „certificate request is being issued“ a nic nemění.
Adopce objeveného certifikátu se už nedotkne spravovaného certifikátu jiného prostředí nebo organizace — Adopce propojí existující spravovaný certifikát se stejným otiskem, doplní jeho prázdná pole, přesune ho do cílového projektu, pokud žádný neměl, a vrátí ho, ale shoda ignorovala prostředí i organizaci: uživatel omezený na dev, který adoptoval v dev, mohl certifikát z prod přesunout, doplnit a přečíst a šlo si přivlastnit certifikát jiné organizace bez projektu. Shoda je nově omezena na certifikáty organizace volajícího (nikdy systémové), upřednostní certifikát v cílovém projektu a prostředí (z několika certifikátů se stejným otiskem, například kopie v dev a v prod, vezme adopce v dev tu z dev a certifikát bez projektu nikdy nepředběhne ten v cílovém projektu) a shoda v jiném prostředí vrací 409 „matching managed certificate is in another environment“ beze změny (hromadná adopce ji započítá u každého certifikátu zvlášť). Přiřazení objevených certifikátů k projektu, který není certifikátový, nově vrací 400, stejně jako adopce.
Interval synchronizace a předstih obnovy účtu CA se ověřují — Připojení nebo úprava účtu CA přijímaly interval synchronizace nula či méně, kvůli kterému plánovač synchronizoval účet (a volal CA) při každém taktu, a záporný předstih obnovy. sync_interval_minutes musí být nově alespoň 1 a renewal_lead_days nezáporné, jinak 400.
Účet CA může odkazovat jen na CA vlastní organizace — ca_authority_id v přihlašovacích údajích interního nebo ACME účtu CA (připojení a úprava) určuje, která CA z účtu vydává, ale přijímalo se jakékoli existující ID CA, včetně CA z projektu jiné organizace. Nově musí jít o CA některého projektu organizace nebo o CA na úrovni organizace, kterou nepoužívá účet jiné organizace; cokoli jiného a neznámé ID vrací 400 „ca_authority_id does not name a CA of this organization“ a nic nemění.
Starší routy účtů CA zůstávají v organizaci volajícího — GET /api/v1/ca-accounts/{id}/products a POST /api/v1/ca-accounts/{id}/sync braly účet jen podle ID, takže držitel ca:read nebo ca:admin mohl číst produkty účtu jiné organizace nebo pro něj spustit synchronizaci produktů (neznámé ID vracelo prázdný seznam nebo 500). Nově vracejí 404, pokud účet nepatří do organizace požadavku, jak tomu u rout s organizací vždy bylo; synchronizace se do auditu zapisuje jen tehdy, když proběhla.
Schémata poskytovatelů CA lze číst s rolí omezenou na projekt — GET /api/v1/ca-providers/schemas a /api/v1/ca-providers/{type}/schema vracejí jen statické popisy podporovaných CA, ale role přiřazená jedinému projektu dostala i s ca:read odpověď 403, takže formulář žádosti o certifikát se pro takové uživatele nenačetl. Obě routy nově přijmou ca:read držené v libovolném projektu; samotné účty CA zůstávají platné pro celou organizaci.
Import klíče objeveného certifikátu se posuzuje v prostředí certifikátu — POST /api/v1/discovered-certificates/{id}/import-key nahrazuje privátní klíč spravovaného certifikátu, ale posuzoval se jen v prostředí požadavku, takže uživatel s oprávněním pro celou organizaci omezený na dev mohl nahradit klíč certifikátu v prod. Nově vyžaduje discovered_cert:write v prostředí a projektu spravovaného certifikátu (jinak 403, klíč zůstane beze změny). Popisy hromadného přiřazení, adopce a ignorování nově uvádějí, že se každý certifikát zkontroluje před jakoukoli změnou (samotné změny se provádějí postupně).
Adopce objevených certifikátů funguje s API tokeny — Adopce (POST /api/v1/discovered-certificates/{id}/adopt) a hromadná adopce (/bulk/adopt) vracely pro API token 403 „organization context is required“, i když token oprávnění měl, protože routy neviděly výchozí organizaci tokenu, zatímco přiřazení fungovalo. Adopce nyní používá stejnou organizaci jako všechny ostatní routy (u relace tu z relace, u tokenu výchozí organizaci). Odmítnutí pro cílový projekt nebo prostředí, ve kterém volající nesmí jednat, nově zní insufficient permissions for environment (dříve access denied); relace a JWT jsou jinak beze změny.
Chyby uložení při importu klíče objeveného certifikátu zůstávají mimo odpověď — Import privátního klíče adoptovaného objeveného certifikátu (POST /api/v1/discovered-certificates/{id}/import-key) vracel 400 s příčinou, když se klíč nepodařilo uložit: chybějící služba pro odložení klíčů v režimu orchestrátoru, správce tajemství, který klíč odmítl (jeho zpráva může uvádět hostitele a cesty), nebo selhání šifrování. Jde o chyby na straně serveru a nově vracejí 500 s obecným Internal server error; příčina jde do logu serveru s ID požadavku. Klíč, který nelze přečíst nebo neodpovídá certifikátu, nadále vrací 400 s důvodem.
Rozhodnutí o žádostech o certifikát se zapisují do auditu — Odeslání, schválení, zamítnutí a archivace žádosti o podpis certifikátu (/api/v1/certificates/csr) nezapisovaly nic do auditního logu. Každá úspěšná změna nově zaznamená certificate_request_submitted, certificate_request_approved, certificate_request_rejected nebo certificate_request_archived s aktérem, žádostí a jejím projektem (důvod zamítnutí je součástí detailu); odmítnutá volání nezapisují nic a žádný záznam neobsahuje klíčový materiál.
Žádosti o certifikát a importy se posuzují ve svém projektu a prostředí — Role přiřazená na jednom projektu nemohla v něm odeslat žádost o certifikát ani importovat certifikát a API token nebo relace omezená na prostředí mohla importovat do libovolného prostředí. POST /api/v1/certificates/csr se nově posuzuje v projektu uvedeném v těle (bez něj smí neprojektovou žádost odeslat jen role, která není omezena na projekty) a routy importu (/api/v1/certificates/import, /import/bulk, /import/file) v projektu a prostředí, které uvádějí (bez prostředí je to prod, bez projektu je třeba role platná pro celou organizaci); hromadný import se odmítne celý, pokud je jedna položka mimo rozsah. Import už existujícího certifikátu jej změní jen volajícímu, který smí importovat v projektu a prostředí tohoto certifikátu (ostatní dostanou 403, ne jeho detaily). Projekt, šablona, CA účet a integrace pro uložení klíče v žádosti nebo importu musí patřit do organizace volajícího a integrace do projektu (jinak 404). Fronta žádostí (seznam, statistiky, schválení, zamítnutí, archivace) zůstává platná pro celou organizaci.
Žádosti o certifikát používají organizaci volajícího, i pro API tokeny — Odeslání žádosti o certifikát (POST /api/v1/certificates/csr) přebíralo organizaci a agenta z těla požadavku, pokud volající nemá vlastní organizaci, což platí pro API tokeny (Terraform, SDK): žádost tokenu se uložila bez organizace nebo v organizaci, kterou klient uvedl, a schválení, zamítnutí či archivace žádosti přes token vždy selhaly. Organizací je nyní vždy organizace volajícího (u relace ta z relace, u API tokenu výchozí organizace), agent se nastaví jen pro vlastní token agenta a seznam, statistiky, schválení, zamítnutí a archivace posuzují žádosti ve stejné organizaci, takže je tokeny mohou používat a token už nevypisuje žádosti všech organizací.
Přiřazení a adopce objevených certifikátů se kontrolují v cílovém projektu a prostředí — Přiřazení objevených certifikátů k projektu (POST /api/v1/discovered-certificates/{id}/assign a /bulk/assign) se na projekt vůbec nedívalo: neznámý projekt skončil databázovou chybou a projekt jiné organizace nebo archivovaný projekt se přijal, čímž se tam přesunul i navázaný spravovaný certifikát. Cíl musí nově být živý projekt organizace požadavku (jinak 404 target certificate project not found) a v něm, v prostředí požadavku i v prostředí každého spravovaného certifikátu, který se s objeveným přesouvá, musí platit discovered_cert:assign (403 insufficient permissions for environment), takže uživatel, který smí přiřazovat jen v dev, nepřesune certifikát z prod. Adopce (/adopt, /bulk/adopt) se posuzuje v projektu a prostředí svého těla stejnou kontrolou jako ostatní routy. Routy objevených a archivovaných certifikátů zůstávají celoorganizační: role přiřazená na jednom projektu k žádné z nich přístup nedává, s API tokenem, relací webového rozhraní ani JWT.
Relace SRP umožňuje jediný důkaz — POST /api/v1/auth/srp/verify ponechal relaci i po špatném důkazu klienta, takže šlo důkaz zkoušet znovu až do vypršení relace (dvě minuty). Relace nyní končí prvním důkazem, správným i špatným; klient, který neuspěl, musí začít znovu přes POST /api/v1/auth/srp/init.
Přihlášení přes Universal Auth neprozradí nedůvěryhodné adrese nic o tajném klíči — POST /api/v1/auth/universal-auth/login kontroloval nejdřív tajný klíč klienta a teprve potom důvěryhodné adresy, takže požadavek z adresy mimo seznam odpovídal 403, když byl klíč platný, a 401, když nebyl — odpověď tak mohl kdokoli použít k ověřování klíčů. Důvěryhodné adresy se nyní kontrolují jako první a nedůvěryhodná adresa dostane stejnou odpověď 401 Invalid credentials jako špatný klíč nebo neznámý klient (klíč se vůbec nekontroluje); důvod (id klienta a adresa) se zapisuje jen do logu serveru. Pokud provozovatel vidí 401 od klienta se správnými údaji, má zkontrolovat důvěryhodné adresy v jeho konfiguraci.
Změny Universal Auth se auditují — Připojení, změna a odebrání Universal Auth u servisní identity (/api/v1/auth/universal-auth/identities/{id}) a vytvoření a zneplatnění jejích klientských tajných klíčů nezapisovaly žádný auditní záznam. Každá změna nyní zapíše ATTACH_UNIVERSAL_AUTH, UPDATE_UNIVERSAL_AUTH, REVOKE_UNIVERSAL_AUTH, CREATE_CLIENT_SECRET nebo REVOKE_CLIENT_SECRET s volajícím uživatelem a adresou; detaily uvádějí servisní identitu, změněná pole a popis tajného klíče, nikdy tajný klíč.
Přihlášení přes LDAP už nezapisuje uživatelské jméno do logu — Přihlášení přes LDAP (POST /api/v1/auth/ldap/login a přihlášení přes LDAP v konzoli) zapisovalo do logu vyhledávací filtr s dosazeným zadaným uživatelským jménem, i když vyhledávání selhalo, a uživatelské jméno zapsalo znovu, když neodpovídal právě jeden uživatel. Log nyní obsahuje jen šablonu filtru, stejně jako test připojení, a uživatelské jméno už ne.
Přihlášení přes SSO má omezení počtu požadavků a maže prošlé stavy OAuth — Každé neautentizované volání GET /api/v1/auth/sso/{entra,github,gitlab}/login uložilo řádek se stavem OAuth, který se po vypršení nikdy nesmazal. Každé přihlášení nyní nejdřív smaže prošlé stavy a tři přihlašovací cesty mají omezení počtu požadavků na IP klienta (30 za sekundu, dávka 60, jako /auth/sso/spnego/login); nad limitem odpovídají 429 (Too many requests).
Řádky logu databáze už neobsahují hodnoty dotazů — Když databázový příkaz selhal nebo trval dlouho, log serveru ho vypsal se všemi dosazenými hodnotami, včetně jednorázových výměnných kódů SSO a tokenů uložených s nimi. Log nyní ukazuje příkaz jen se zástupnými symboly.
Přihlášení přes Entra ID bez konfigurace se vrací na přihlašovací stránku — GET /api/v1/auth/sso/entra/login odpovídal surovým JSON 500 (Failed to initiate SSO login), když nebyla nastavena adresa pro přesměrování, takže prohlížeč zobrazil chybovou stránku. Nyní přesměruje (302) na přihlašovací stránku konzole s ?error=sso_not_configured (při jiné chybě ?error=sso_failed, se záznamem v logu), přes FRONTEND_URL nebo hostitele, odkud požadavek přišel, stejně jako callback.
Callbacky SSO hlásí pevné chybové kódy — Neúspěšný callback Entra ID, GitHub nebo GitLab vkládal interní text chyby do přesměrování (/login?error=<zpráva>), takže se podrobnosti poskytovatele identity nebo serveru mohly dostat do historie prohlížeče a do logů. Parametr error je nyní jeden z kódů missing_auth_code, missing_code_or_state, invalid_state (neznámý nebo prošlý stav OAuth) a sso_failed; podrobnosti se zapisují jen do logu serveru.
Přihlášení přes SSO už nikdy nedává přístupový token do URL — Když se nepodařilo uložit jednorázový výměnný kód přihlášení přes Entra ID, GitHub nebo GitLab, callback (GET /api/v1/auth/sso/{entra,github,gitlab}/callback) náhradně přesměroval na /login?access_token=<JWT> a nastavil cookie s obnovovacím tokenem, takže token skončil v historii prohlížeče, v logu proxy a v hlavičce Referer. Přihlášení nyní místo toho selže: přesměruje na /login?error=sso_failed bez tokenu i cookie; příčina se zaloguje.
Test připojení LDAP už nezapisuje testovací uživatelské jméno do logu — POST /api/v1/auth/sso/ldap/test zapisoval volitelné test_username do logu serveru, i uvnitř zalogovaného vyhledávacího filtru. Log nyní obsahuje jen informaci, zda bylo testovací jméno zadáno, a šablonu filtru.
Změny poskytovatelů identity a SPNEGO se auditují — Vytvoření, úprava a smazání poskytovatele identity (/api/v1/identity-providers) a uložení konfigurace SPNEGO/Kerberos (POST /api/v1/auth/sso/spnego/config) nezapisovaly žádný auditní záznam. Nyní zaznamenají CREATE_IDENTITY_PROVIDER, UPDATE_IDENTITY_PROVIDER, DELETE_IDENTITY_PROVIDER a CONFIGURE_SPNEGO (entita IDENTITY_PROVIDER) s uživatelem a IP adresou; podrobnosti uvádějí název a typ poskytovatele, případně service principal a realm, nikdy tajemství.
Heslo pro bind LDAP, které nelze zašifrovat, se už neukládá v čitelné podobě — Když heslo pro bind poskytovatele identity LDAP nešlo zašifrovat, POST /api/v1/identity-providers a PUT /api/v1/identity-providers/{id} je potichu uložily nešifrované. Nyní vrací 500 (Internal server error) a nic neuloží; příčina se zapíše do logu.
Hledání skupin poskytovatele identity mohlo změnit filtr Graph — GET /api/v1/identity-providers/{id}/groups?search=… vkládal hledaný text do filtru $filter Microsoft Graph v uvozovkách bez escapování apostrofů, takže hledání obsahující ' mohlo řetězec ukončit a přidat vlastní podmínky filtru. Apostrofy se nyní zdvojují, jak řetězcové literály OData vyžadují, a hledání se vždy porovnává jako začátek zobrazovaného názvu.
Odpovědi poskytovatelů identity a konfigurace LDAP už nevracejí uložená tajemství — POST /api/v1/identity-providers a PUT /api/v1/identity-providers/{id} vracely uloženou konfiguraci celou, takže i úprava, která měnila jen název, vrátila client_secret Entra ID v čitelné podobě (a zašifrovaný bind_password LDAP). Nyní maskují client_secret, bind_password, api_token a token stejně jako výpis a detail (**** a poslední čtyři znaky). POST /api/v1/auth/sso/ldap/config nyní vrací heslo pro bind jako __MASKED__, stejně jako GET.
Bezpečnostní hlavičky webového rozhraní (nálezy OWASP ZAP) — Každá odpověď webového rozhraní nově obsahuje Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy a Cross-Origin-Resource-Policy a statické soubory nově dostávají i X-Content-Type-Options: nosniff (nginx ho u nich zahazoval). Statické soubory už neposílají Access-Control-Allow-Origin: *. Content Security Policy (sestavená pro každou odpověď, s hashi sha256- inline skriptů aplikace v script-src) a Cross-Origin-Embedder-Policy: require-corp se vynucují; už nejsou jen v režimu hlášení. Statické soubory se servírují předkomprimované (gzip, brotli). Chybějící soubory jako favicon.ico nebo sitemap.xml vracejí 404 místo stránky aplikace a robots.txt zakazuje indexaci. Zastaralá hlavička X-XSS-Protection byla odstraněna. Hlavičky nastavuje samotná webová aplikace (server Nuxt), takže jsou stejné za edge v Docker Compose i za ingressem v Helmu; stránky /swagger servíruje backend a aplikační CSP nenesou.
Přihlášení přes SAML už nevystavuje refresh token prohlížeči — Endpoint SAML ACS (POST /api/v1/auth/saml/callback) dříve na platnou aserci odpovídal JSON tělem s access_token a refresh_token, které mohl číst JavaScript v prohlížeči. Nyní funguje stejně jako přihlášení přes Entra ID, GitHub a GitLab: uloží jednorázový výměnný kód platný 60 sekund a přesměruje (302) na FRONTEND_URL/login?sso_code=… (bez FRONTEND_URL na hostitele, na kterém byl callback volán); konzole kód vymění přes POST /api/v1/auth/sso/exchange, který vrací jen access token a refresh token nastaví jako HttpOnly cookie. Opakovaně použitý nebo expirovaný kód je odmítnut s 401. Callback odesílá poskytovatel identity přes prohlížeč uživatele a konzole, SDK ani Terraform provider jej nikdy nekonzumovaly, takže integrace není třeba měnit; pokud je konzole servírována z jiného originu než API, nastavte FRONTEND_URL.
Odstraněny tranzitivní CVE v Go (x/net, x/mod) — golang.org/x/net byl povýšen 0.55.0 → 0.56.0 a golang.org/x/mod 0.37.0 → 0.40.0 napříč moduly agent, cli, k8s-operator a terraform-provider-mazevault kvůli vyřešení CVE-2026-46600, CVE-2026-56864 a CVE-2026-56865.
Aktualizace závislostí napříč moduly — Byly aktualizovány další modulové závislosti: golang.org/x/crypto → 0.55.0 a golang.org/x/sys → 0.47.0 v ocsp-responder, cloud.google.com/go a související balíčky v backend a google.golang.org/grpc, google.golang.org/genproto a balíčky OpenTelemetry v terraform-provider-mazevault.
Odstraněn gRPC DoS (CVE-2026-84445) — google.golang.org/grpc byl povýšen 1.83.1 → 1.83.2 v backend a terraform-provider-mazevault kvůli vyřešení CVE-2026-84445 (odepření služby v gRPC-Go přes chybně formovaný RPC požadavek), na kterém padal Trivy filesystem sken dev-pipeline. Oprava je fixována na patch řadu 1.83.2 (řada 1.84.0 je stále zasažena). Transitivní golang.org/x/mod → 0.40.0 (CVE-2026-56864 / CVE-2026-56865), který následná aktualizace nástrojů stáhla zpět na 0.39.0, byl znovu aplikován. Ověřeno go build, go vet, govulncheck (0 dosažitelných) a čistým Trivy skenem CRITICAL,HIGH --ignore-unfixed.
Odstraněn Jackson Core/Databind DoS (CVE-2026-68497, CVE-2026-89407, CVE-2026-89425, CVE-2026-91776, CVE-2026-91777) — com.fasterxml.jackson.core:jackson-databind byl v Java SDK (sdks/java/pom.xml) povýšen 2.18.8 → 2.18.11. Prvotní bump → 2.18.10 vyřešil CVE-2026-68497 (DoS vytížením CPU přes neohraničené parsování čísel); následná vlna Jackson advisories pak označila čtyři další HIGH DoS — dva v tranzitivním jackson-core (CVE-2026-89407 regex backtracking, CVE-2026-89425 neohraničený růst StringBuilder) a dva v jackson-databind (CVE-2026-91776 neohraničený růst cache, CVE-2026-91777 kvadratické forward-reference) — všechny opravené ve 2.18.11, která tranzitivně srovná i jackson-core → 2.18.11. Vše zůstává na patch řadě 2.18.x (drop-in, bez změn API) a Trivy filesystem sken dev-pipeline je zelený. Java SDK nyní importuje Jackson BOM (com.fasterxml.jackson:jackson-bom, pinnutý přes jedinou property jackson.version) v dependencyManagement, takže jackson-core, jackson-databind i jackson-annotations zůstávají verzově zarovnané a budoucí bumpy Jacksonu jsou změna na jednom řádku.
Odstraněn x/net HTTP/2 DoS (CVE-2026-78669) — golang.org/x/net byl povýšen → 0.60.0 v modulech backend, agent, cli, k8s-operator a terraform-provider-mazevault kvůli vyřešení CVE-2026-78669 (odepření služby v net/http2 přes nadměrné HTTP/2 SETTINGS rámce), na kterém padal Trivy filesystem sken dev-pipeline. Všech pět modulů se čistě buildí i testuje a Trivy sken CRITICAL,HIGH --ignore-unfixed je zelený napříč všemi moduly.
Druhá vlna závislostí (ověřeno) — Byla aplikována a ověřena další dávka bezpečných bumpů (backend go build/vet/plný go test, agent build/test linux+windows, frontend tsc -b/lint/build/165 testů na Node 24, Trivy, govulncheck): Go moduly backendu (Azure azcore 1.23.2 / azidentity 1.14.1, azblob 1.8.2, aws-sdk-go-v2/config 1.33.8, service/s3 1.114.2, gin-contrib/cors 1.7.9, go-ldap/ldap/v3 3.4.15, microsoft/go-mssqldb 1.11.2, golang.org/x/crypto 0.57.0, golang.org/x/oauth2 0.37.0, golang.org/x/time 0.16.0, google.golang.org/api 0.301.0 — ta tranzitivně posunula google.golang.org/grpc → 1.84.0, kterou aktuální databáze Trivy pro CVE-2026-84445 už neflaguje, a koordinovaný lockstep bump k8s.io/api + k8s.io/apimachinery + k8s.io/client-go 0.28.0 → 0.37.1, proti kterému se Kubernetes rotační kroky čistě buildí i testují); npm balíčky frontendu (lucide-react 1.50.0, @types/node 26.6.4, globals 17.13.0, vitest 5.0.3); a GitHub Actions (actions/checkout, actions/setup-go, actions/setup-node v5 → v7 a actions/download-artifact v4 → v8, která zůstává kompatibilní s již připnutým actions/upload-artifact@v7 a stahováním podle name/pattern v tomto repu). Odloženo (blokováno): dříve sledované PR typescript 7 a eslint 10 (stále blokované peer rozsahy ESLintu).
Konsolidované aktualizace závislostí — Byla aplikována a end-to-end ověřena velká dávka rutinních aktualizací (backend/agent go test, frontend tsc/lint/build/165 testů na Node 24, Trivy, govulncheck): Go moduly backendu (microsoftgraph/msgraph-sdk-go, swaggo/swag, swaggo/gin-swagger, Azure azcore/azblob, Venafi/vcert, aws-sdk-go-v2 core/config/credentials/s3/route53, gin-contrib/cors, jackc/pgx, miekg/pkcs11, lib/pq, mongo-driver, crewjam/saml, prometheus/client_golang, stretchr/testify), Go moduly agenta (go-resty, prometheus/client_golang, golang.org/x/crypto 0.57.0, golang.org/x/sys 0.48.0, go-pkcs12 0.7.3), npm balíčky frontendu (react/react-dom 19.3.0, react-router 8.4.0, axios 1.20.0, date-fns, jspdf-autotable, @noble/hashes a @noble/ciphers 2.4.0, lucide-react 1.x, @types/node 26, @testing-library/react a user-event, @vitejs/plugin-react 6, globals 17, autoprefixer, @tailwindcss/postcss, eslint-plugin-react-refresh, vite-plugin-node-polyfills), základní image kontejnerů (alpine 3.21 → 3.24 pro init-certs, python 3.12-alpine → 3.14-alpine pro build stage dokumentace) a GitHub Actions (actions/upload-artifact 4 → 7, actions/github-script 7 → 9, azure/aks-set-context 4 → 5, azure/login 2 → 3, codecov/codecov-action 4 → 7, github/codeql-action 3 → 4, docker/build-push-action 6 → 7, docker/setup-buildx-action 3 → 4, docker/login-action 3 → 4, zaproxy/action-baseline 0.14 → 0.15). Automatické PR závislostí se nyní otevírají proti integrační větvi dev (Dependabot target-branch: dev pro každý ekosystém) místo výchozí větve. Odloženo (blokováno upstreamem, ponecháno jako otevřené sledované PR): typescript 7 (blokuje peer typescript <6.1.0 v typescript-eslint) a eslint 10 / @eslint/js 10 (blokuje eslint-plugin-react, který zatím nedeklaruje peer eslint ^10).
Material UI povýšeno na v9 (major, frontend) — Administrátorská konzole byla migrována z Material UI 7 na @mui/material / @mui/icons-material 9.4.0 a @mui/x-date-pickers 9.14.0. Všechna odebraná/přejmenovaná v9 API byla migrována oficiálními MUI codemody plus cílenými opravami: zastaralé systémové style-propy (fontWeight, display, fontFamily, alignItems, fontStyle, spacing, …) přesunuty do sx; legacy slot-propy TextField/Dialog/Checkbox/Autocomplete (InputProps, inputProps, InputLabelProps, SelectProps, PaperProps, TransitionProps) přesunuty do sjednoceného API slotProps; odebrané ikony *Outline přesměrovány na ekvivalenty *OutlineOutlined; a theme override MuiButton containedPrimary přepsán přes v9 API variants. Jde o interní upgrade frontendové knihovny komponent bez změny aplikačních rout, chování nebo backend/API kontraktů; kompletní TypeScript type-check, ESLint, produkční build i sada 165 unit testů procházejí.
Build/test frontendu vyžaduje Node ≥ 22.22 — Testovací toolchain byl povýšen na vitest 5 a jsdom 30, jejichž vestavěné undici vyžaduje runtime API Node (webidl.util.markAsUncloneable) dostupné až na Node ≥ 22.22. CI i Docker image frontendu už běží na Node 24; do kořene repozitáře a do frontend/ byly přidány soubory .nvmrc (fixované na Node 24), takže lokální vývoj vybere kompatibilní runtime automaticky.
Autentizační cookies mají SameSite=Lax (nález OWASP ZAP) — Cookies refresh_token a XSRF-TOKEN se při COOKIE_SECURE=true posílaly se SameSite=None, takže je prohlížeč přikládal i k požadavkům z cizích webů. Nově mají vždy SameSite=Lax; COOKIE_SECURE dál řídí jen příznak Secure. Webové rozhraní volá API vždy na vlastním originu a přihlášení přes SSO (Entra, GitHub, GitLab, SAML) se nemění. Existující relace pokračují: refresh cookie dostane nový atribut při dalším obnovení tokenu.
Cache API a ochrana proti cross-site požadavkům (nálezy OWASP ZAP) — Odpovědi API mají nově výchozí Cache-Control: no-store, no-cache, must-revalidate a X-Content-Type-Options: nosniff, takže odpovědi přihlášení, obnovení tokenu, SSO ani stavové odpovědi neukládá prohlížeč ani proxy; CRL a ACME si ponechávají vlastní cache politiku. Izolace zdrojů podle Fetch Metadata odmítne cross-site požadavky prohlížeče s 403, pokud nejde o navigaci na nejvyšší úrovni, POST se SAML assertion nebo o origin uvedený v CORS_ALLOWED_ORIGINS. Klientů mimo prohlížeč (agenti, gatewaye, SCEP/ACME/OCSP, CLI, Terraform) se změna netýká. Pokud API volá prohlížečová aplikace z jiné domény, uveďte její origin v CORS_ALLOWED_ORIGINS.
Serverové relace prohlížeče pro webové rozhraní — Backend nově umí držet relace prohlížeče na straně serveru (tabulka ui_sessions, migrace 000208–000210) za endpointy jen pro BFF /api/v1/ui/auth/* a schématem Authorization: Session, které se přijímá pouze spolu s hlavičkou X-MazeVault-BFF obsahující BFF_SHARED_SECRET. Administrátoři mohou relace uživatele vypsat a zrušit přes GET/DELETE /api/v1/rbac/users/{id}/sessions. Nové webové rozhraní je používá (viz „Nové webové rozhraní“). Relace končí po UI_SESSION_IDLE_TIMEOUT (30 minut) nečinnosti nebo po UI_SESSION_ABSOLUTE_TIMEOUT (12 hodin), čekající krok MFA po UI_SESSION_MFA_TIMEOUT (5 minut); ruší se při změně hesla (kromě volající relace), smazání uživatele, přiřazení nebo odebrání role, vypnutí MFA a změně rolí přes SSO/LDAP.
Nová nastavení — TRUSTED_PROXIES, UI_SESSION_IDLE_TIMEOUT, UI_SESSION_ABSOLUTE_TIMEOUT, UI_SESSION_MFA_TIMEOUT a tajemství BFF_SHARED_SECRET (viz Proměnné prostředí). Instalátory a upgrade-mazevault.sh generují BFF_SHARED_SECRET; v Helmu je povinný (global.keyVault.secretKeys.bffSharedSecret, viz Změny distribuce). upgrade-mazevault.sh nainstaluje docker-compose.yml z kitu (po zálohování). Lokální vývojáři jednou znovu spustí ./secrets.sh.
Požadavky z BFF projdou kontrolou CSRF cookie — Požadavek měnící stav, jehož hlavička X-MazeVault-BFF odpovídá BFF_SHARED_SECRET (porovnání v konstantním čase), už nepotřebuje dvojici cookie XSRF-TOKEN: frontendový server (BFF) původ prohlížeče už ověřil a anonymní volání přes něj, například vyzvednutí sdíleného tajemství, žádné cookies nenese. Nenastavené tajemství nic nevyjímá; ostatní požadavky se kontrolují jako dosud.
IP klienta se z X-Forwarded-For bere jen od důvěryhodných proxy (změna chování) — Hlavička X-Forwarded-For od peerů mimo TRUSTED_PROXIES (výchozí: loopback a privátní rozsahy v backendu a v Helmu, podsíť kitu MAZEVAULT_SUBNET v Docker Compose) se nově ignoruje, což mění IP klienta v auditním logu a v rate limitech, pokud má proxy veřejnou adresu. Takové proxy uveďte v TRUSTED_PROXIES. Naopak v sítích, kde mají privátní adresy i nedůvěryhodní klienti, nastavte TRUSTED_PROXIES na přesné adresy nebo podsítě edge/ingressu, jinak mohou X-Forwarded-For podvrhnout.
Tokeny relace MFA jsou jednorázové — Token vydaný po kroku s heslem šlo opakovaně použít na POST /api/v1/auth/mfa/verify až do vypršení; nově se spotřebuje prvním úspěšným ověřením.
Odhlášení zneplatní refresh token — POST /api/v1/auth/logout nově maže i uložený refresh token (odcizený token už odhlášení nepřežije) a zapisuje auditní záznam LOGOUT.
Ověření MFA má rate limit a omezený počet pokusů — POST /api/v1/auth/mfa/verify má rate limit a relace MFA povolí nejvýše 5 pokusů o kód; poté je nutné nové přihlášení (audit VERIFY_MFA_LOCKED).
Změny provisioningu přes SCIM se auditují — Vytvoření, úprava a smazání uživatele a vytvoření, patch a smazání skupiny přes SCIM (/api/v1/auth/scim/{providerID}) nezapisovaly žádný auditní záznam. Nyní zaznamenají CREATE_SCIM_USER, UPDATE_SCIM_USER, DELETE_SCIM_USER, CREATE_SCIM_GROUP, PATCH_SCIM_GROUP a DELETE_SCIM_GROUP (entity SCIM_USER a SCIM_GROUP) s IP adresou klienta, připsané systémovému uživateli, protože SCIM token neidentifikuje osobu; podrobnosti uvádějí poskytovatele a zdroj, nikdy token.
Odpovědi poskytovatelů identity už neobsahují hash SCIM tokenu — Cesty poskytovatelů identity (/api/v1/identity-providers) maskovaly tajemství konfigurace poskytovatele, ale uložený scim_token_hash (bcrypt hash SCIM bearer tokenu poskytovatele) vracely v čitelné podobě. Nyní je maskovaný jako client_secret a úprava, která pošle zpět masku nebo nechá pole prázdné, uložený hash zachová.
Chyby SCIM už neobsahují text databáze — Selhávající operace SCIM odpovídala 500 se surovou chybou služby, takže id, které není UUID, u DELETE/PUT/PATCH pod /api/v1/auth/scim/{providerID}/Users/{id} a /Groups/{id}, nebo hodnota odmítnutá databází vrátily text chyby PostgreSQL (invalid input syntax for type uuid ... SQLSTATE 22P02). Id, které není UUID, nyní odpovídá 404 User not found / 404 Group not found jako neznámé id a každé jiné selhání odpovídá 500 Internal server error s příčinou jen v logu serveru.
Cesty konfigurace LDAP nevracejí uložená tajemství v čitelné podobě — GET a POST /api/v1/auth/sso/ldap/config maskovaly jen heslo pro bind. Pokud konfigurace poskytovatele LDAP obsahovala i client_secret, api_token, token nebo scim_token_hash, vracela se v čitelné podobě. Nyní maskují stejná tajemství jako cesty poskytovatelů identity (**** a poslední čtyři znaky; heslo pro bind zůstává zástupnou hodnotou __MASKED__) a uložení konfigurace LDAP zachová uložené tajemství, které požadavek vynechá, nechá prázdné nebo zamaskované, místo aby ho zahodilo.
Neaktivní poskytovatel identity nepřijímá volání SCIM — Cesty SCIM (/api/v1/auth/scim/{providerID}) přijímaly vytváření, úpravy a mazání uživatelů a skupin i pro poskytovatele identity, který byl vypnutý (stav inactive), pokud byl SCIM token správný. Takový poskytovatel nyní na každé volání, včetně čtení, odpovídá 403 SCIM not enabled for this provider, tedy jako poskytovatel bez SCIM, a to před kontrolou tokenu.
Neaktivní poskytovatel identity nepřijímá zápisy přes SCIM — Cesty SCIM (/api/v1/auth/scim/{providerID}) přijímaly vytváření, úpravy a mazání uživatelů a skupin i pro poskytovatele identity, který byl vypnutý (stav inactive), pokud byl SCIM token správný. Takový poskytovatel nyní na každý zápis odpovídá 403 SCIM not enabled for this provider, tedy jako poskytovatel bez SCIM, a to před kontrolou tokenu; čtení nadále funguje.
Zápisy v2 secretů se kontrolují v prostředí, kterého se týkají — Kontrola oprávnění u POST /api/v2/secrets, PUT a DELETE /api/v2/secrets/{id} a POST /api/v2/secrets/migrate posuzovala jen prostředí, na které se požadavek přeložil, takže uživatel, jehož role uděluje secret:write nebo secret:delete jen v dev, mohl vytvořit secret v prod nebo prod secret změnit, smazat či migrovat. Každá z těchto operací nyní vyžaduje oprávnění v prostředí z těla požadavku nebo secretu (a na jeho projektu u role omezené na projekt) a jinak před jakoukoli změnou vrací 403 insufficient permissions for environment; migrace secretu z projektu, který role nepokrývá, se hlásí jako secret not found. Požadavky na prostředí, na které se přeložily, se chovají jako dříve. Rozhodnutí o oprávnění se nově cachují i podle organizace a projektu.
Zápisy v1 secretů se kontrolují v prostředí, kterého se týkají — Kontrola oprávnění u zapisovacích v1 routes secretů posuzovala jen prostředí, na které se požadavek přeložil, takže uživatel, jehož role uděluje secret:write, secret:delete, secret:archive nebo životní cyklus archivu jen v dev, mohl vytvořit secret v prod, nebo jej aktualizovat, smazat, vrátit verzi, zkopírovat, archivovat, obnovit, smazat natrvalo, synchronizovat či do něj importovat. Vytvoření, import a cíl kopie nyní vyžadují oprávnění v prostředí z těla požadavku; každá routa podle id secretu je vyžaduje v prostředí samotného secretu (kopie také secret:read v prostředí zdroje, vynucená synchronizace jednoho prostředí v synchronizovaném) a u role omezené na projekt i na projektu secretu. Vracejí 403 insufficient permissions for environment před jakoukoli změnou. Požadavky na prostředí, na které se přeložily, se chovají jako dříve; klient, který zapisuje do jiného prostředí, než jaké posílá v hlavičce či parametru prostředí, nyní potřebuje roli, která toto prostředí pokrývá.
Čtení secretů se kontroluje v prostředí, kterého se týká — Kontrola oprávnění u čtecích routes secretů posuzovala jen prostředí, na které se požadavek přeložil, takže uživatel, který smí číst jen dev, mohl přečíst prod secret podle id: GET /api/v1/secrets/{id} vracel jeho dešifrovanou hodnotu a čitelné byly i jeho verze, stav synchronizace, stav offloadu a log synchronizace. Tyto routes nyní vyžadují secret:read v prostředí samotného secretu a u role omezené na projekt i na jeho projektu a před jakýmkoli čtením či dešifrováním vracejí 403 insufficient permissions for environment. GET /api/v1/projects/{id}/secrets bez filtru prostředí vypíše jen prostředí, která uživatel smí číst, a čtení v2 i porovnání kontrolují také projekt. POST /api/v1/secrets/drift/detect bez project_id (všechny projekty) vyžaduje oprávnění na všech projektech, takže role na jednom projektu musí předat jeho project_id. Selhání vyhledání oprávnění nyní požadavek odmítne, místo aby ho propustilo.
Výpisy secretů se kontrolují pro projekt a požadované prostředí — GET /api/v2/projects/{id}/secrets a /secrets/matrix posuzovaly prostředí, která uživatel smí číst, bez projektu, takže uživatel, který smí číst dev všude a prod jen na projektu A, dostal i prod secrety projektu B (jejich zašifrovaný název, hodnotu a nonce). Nyní posuzují každé prostředí pro daný projekt. GET /api/v1/projects/{id}/secrets?environment=X se posuzoval v prostředí, na které se požadavek přeložil, což na serveru s nakonfigurovanými prostředími není X; nyní vyžaduje secret:read přímo v X a jinak vrací 403 insufficient permissions for environment.
Matice v2 secretů je prázdná, když není čitelné žádné prostředí — GET /api/v2/projects/{id}/secrets/matrix si vyžádala všechna prostředí, když uživatel nemohl číst žádné z prostředí organizace, takže uživatel, který smí číst jen prostředí mimo seznam organizace (nebo kdokoli v organizaci bez prostředí), dostal všechny řádky secretů projektu. Nyní v tomto případě nevrací žádné řádky, stejně jako výpis.
Role omezené na prostředí a projekt platí i pro uživatele v prohlížeči — Relace webového rozhraní a JWT uživatele nesly roli zobrazenou u uživatele a kontrola oprávnění tuto roli udělovala ve všech prostředích a projektech, navíc k omezeným přiřazením uživatele. Šlo o nejvyšší roli, kterou uživatel měl v jakémkoli rozsahu, takže uživatel s rolí Secret Manager jen pro dev mohl z prohlížeče číst a měnit secrety v prod i v jiných projektech (API tokeny už omezeny byly). Uživatel nyní dostane přesně ta přiřazení rolí, která platí pro prostředí, projekt a organizaci, jichž se požadavek týká, ať se přihlásí jakkoli; token agenta si svou roli ponechává. Přiřazení omezené na projekt nebo organizaci se počítá jen pro požadavek v tomto projektu nebo organizaci; dříve se počítalo i na každé cestě bez projektu, takže role přiřazená pro jeden projekt (například admin) si mohla přiřadit libovolnou roli všude. Projekt požadavku je ten, který jmenuje jeho cesta, nebo ten, kterému patří secret (i archivovaný, který se obnovuje nebo trvale maže), certifikát, žádost o schválení či politika schvalování, integrace projektu, synchronizační pravidlo nebo konflikt, skupina konzistence nebo varování konzistence, které jmenuje (neznámé id dál vrací 404). project_id v dotazu nebo v JSON těle se počítá jen na cestách, které s tímto projektem pracují (GET a POST /api/v1/secrets/, GET a POST /api/v2/secrets, POST /api/v2/secrets/compare, POST /api/v1/secrets/drift/detect, GET /api/v1/consistency-groups); jinde rozsahem není a hodnota odlišná od projektu cesty se odmítne kódem 403, ať má tělo jakýkoli Content-Type. Kontrola přečte každé zapisující tělo dřív, než ho dostane handler, a to stejně, jak ho handlery dekódují (první JSON hodnotu, klíče v libovolné velikosti písmen): project_id/organization_id, které nejsou řetězcem, se berou jako projekt či organizace, kde nikdo nemá omezenou roli, nečitelné tělo vrací 400 a tělo nad 16 MiB 413; volající bez oprávnění cesty kdekoli se odmítne dřív, než se jeho tělo přečte. Úpravy synchronizačních pravidel, politik schvalování a konfiguračních šablon už nezapisují libovolné pole z těla (gorm bral názvy sloupců i polí Go, takže klíč ProjectID přesunul pravidlo nebo politiku do jiného projektu): mění se jen jejich měnitelná pole a synchronizační pravidlo (i při vytvoření) přijme jen integraci vlastního projektu. U PUT /api/v1/certificates/{id} a PUT /api/v1/rotation/templates/{id} je project_id v těle cílem přesunu: oprávnění musí platit v projektu zdroje i v cílovém projektu. Požadavky s API tokenem patří do výchozí organizace vlastníka tokenu stejně jako relace v prohlížeči; požadavek, který jmenuje jinou organizaci (cestou, parametrem dotazu nebo polem těla organization_id), potřebuje oprávnění i v ní. Cesty, které pracují s více projekty (GET /api/v1/projects/, POST /api/v1/secrets/drift/detect bez project_id, POST /api/v2/secrets/migrate), přijmou roli na libovolném projektu a pak pracují po projektech: seznam projektů vrátí jen projekty, které uživatel smí číst. Kontrola pojmenování secretu (POST /api/v1/organizations/{id}/secret-naming-policy/check) také přijme config:read v libovolném projektu, takže uživatelé projektu dostanou nápovědu; vytvoření secretu politiku vynutí znovu. GET /api/v1/auth/me/permissions přijímá volitelný project_id a pak vypíše oprávnění v tomto projektu a pod environments oprávnění v tomto projektu pro každé prostředí organizace; seznamy oprávnění nyní počítají i přiřazení organizace a přidávají any_project_permissions, oprávnění držená alespoň v jednom projektu (podle nich se zobrazí stránka Projekty a její položka v postranním menu). Na stránce projektu webové rozhraní kontroluje oprávnění v tomto projektu, takže uživatel s rolí na jednom projektu vidí tento projekt a jeho akce. Role zobrazená u uživatele je nyní nejvyšší role přiřazená bez omezení (Viewer, pokud žádná není) a slouží jen jako označení. Každá cesta, která vytváří uživatele (lokální, LDAP, Entra ID, GitHub, GitLab, OIDC, SAML, SPNEGO, SCIM a administrátorské účty vytvářené při startu), mu nyní také všude přiřadí jeho výchozí roli, a migrace 000216 (idempotentní) to udělá pro stávající uživatele, kteří nemají žádné přiřazení role, takže si roli, kterou měli, ponechají. Role z tokenu se nyní uplatní jen u strojového subjektu (JWT agenta nebo servisní identity): dosud platný JWT smazaného uživatele už svou roli nenese.
Přiřazení rolí z Terraformu a Go SDK si ponechají rozsah — mazevault_user_role (a AssignRole v Go SDK) posílaly project_id a environment na nejvyšší úrovni těla POST /api/v1/rbac/users/{id}/roles, kde server četl jen scope, takže přiřazení vzniklo bez rozsahu: role platila ve všech projektech a prostředích. SDK a provider nyní posílají scope a server bere project_id/environment z nejvyšší úrovně jako rozsah, když scope chybí (požadavek, kde jsou obojí a liší se, vrací 400). mazevault_sync_rule.project_id nyní vynutí nahrazení (pravidlo nelze přesunout mezi projekty).
Žádosti o schválení přebírají jen pole žadatele — POST /api/v1/projects/{id}/approval-requests vázal celý model žádosti, takže žadatel mohl vytvořit žádost už ve stavu approved, s rozhodnutími, vlastním id, časovými údaji či expirací, nebo s politikou jiného projektu. Nyní přebírá jen request_type, resource_type, resource_id, action, details, reason, urgency a policy_id; zbytek nastaví server (nová žádost je pending, potřebuje jednoho schvalovatele a vyprší po 48 hodinách) a politika jiného projektu vrací 400.
Certifikátové endpointy se kontrolují v projektu a prostředí samotného certifikátu — Kontrola oprávnění certifikátových endpointů se dívala na prostředí, ve kterém se požadavek vyhodnotil, a u uživatele s rolí přiřazenou k jednomu projektu na projekt uvedený v požadavku, nikoli na samotný certifikát. GET, PUT, POST …/archive, …/revoke, …/unrevoke a GET …/targets pod /api/v1/certificates/{id} nyní posuzují oprávnění v prostředí a projektu certifikátu a jinak vrací 403 insufficient permissions for environment; úprava, která certifikát přesouvá nebo uvádí prostředí, se posuzuje i v projektu a prostředí, kam se přesouvá. Obnovení a trvalé smazání certifikátu (POST …/restore, DELETE …/permanent) nyní zohledňují roli omezenou na projekt certifikátu, takže správce projektu je může provést pro svůj projekt (dříve je odmítla každá role omezená na projekt). Certifikát bez projektu je dostupný jen uživateli, jehož oprávnění není omezeno na některé projekty.
Seznam certifikátů ukazuje jen to, co uživatel smí číst — GET /api/v1/certificates/ (i jeho zobrazení enriched) je nyní endpoint „libovolného projektu“: uživatel s rolí přiřazenou k jednomu projektu (nebo omezenou na některá prostředí) projde kontrolou oprávnění a dostane certifikáty, které smí číst v projektu a prostředí samotného certifikátu, místo 403 pro roli přiřazenou k jednomu projektu. Role omezená na některá prostředí, ale ne na projekt, kontrolou oprávnění už procházela (v prostředí požadavku) a dostávala certifikáty všech prostředí včetně prod; nyní dostane certifikáty prostředí, která smí číst. project_id seznam jen filtruje a nikdy nerozšiřuje. Certifikát bez projektu se zobrazí jen uživateli, jehož oprávnění není omezeno na některé projekty; kdo nesmí číst žádný, dostane prázdný seznam.
Export certifikátu se kontroluje v prostředí a projektu samotného certifikátu — GET /api/v1/certificates/{id}/export vyžadoval certificate:read jen v prostředí, ve kterém se požadavek vyhodnotil, takže uživatel s rolí omezenou na jedno prostředí mohl stáhnout certifikát jiného prostředí (a na požádání i s privátním klíčem). Nyní posuzuje oprávnění v prostředí a projektu certifikátu a jinak vrací 403 insufficient permissions for environment; certifikát bez projektu exportuje jen uživatel, jehož oprávnění není omezeno na některé projekty.
Projektové endpointy certifikátů a správců tajemství se kontrolují v prostředí daného záznamu — GET /api/v1/projects/{id}/certificates/{certId} a seznam certifikátů projektu (GET …/certificates) vyžadovaly certificate:read jen v prostředí, na které se požadavek převedl, takže uživatel s rolí omezenou na dev mohl číst certifikát z prod podle id a vidět ho v seznamu. Endpoint podle id nyní vyžaduje oprávnění v prostředí certifikátu a seznam ponechá certifikáty prostředí, která uživatel smí číst. GET …/integrations/{integrationId}/secrets se kontroluje v prostředí, ke kterému je integrace vázána, a GET …/integrations/secret-managers (který vypisuje integrace všech projektů organizace) ponechá jen ty, které uživatel smí číst ve svém projektu a prostředí: uživatel s rolí přiřazenou k jednomu projektu tu už nevidí názvy a poskytovatele správců tajemství ostatních projektů.
Přiřazení šablony přijme jen účet CA z organizace projektu — POST /api/v1/projects/{id}/templates/{template_id} ukládalo override_ca_account_id z těla bez kontroly, takže šlo projekt nastavit k vydávání z účtu CA jiné organizace (nebo neexistujícího). Účet musí patřit organizaci projektu, jinak endpoint vrací 400 a nic nepřiřadí.
Stav odvolání certifikátu se kontroluje v prostředí a projektu samotného certifikátu — GET /api/v1/certificates/{id}/status neměl žádnou kontrolu oprávnění, takže každý přihlášený uživatel (i role bez oprávnění k certifikátům nebo přiřazená k jinému projektu či prostředí) mohl číst stav, sériové číslo a datum odvolání libovolného id certifikátu. Nyní vyžaduje certificate:read v prostředí a projektu certifikátu, jinak vrací 403 insufficient permissions for environment.
Projektové routy pro HSM a externí CA odstraněny — POST /api/v1/projects/{id}/ca/{caId}/hsm a POST /api/v1/projects/{id}/ca/{caId}/external/configure používaly id projektu z cesty jako id CA, takže uživatel s ca:admin přiřazeným celé organizaci (ne omezeným na projekt) mohl nastavit konfiguraci HSM nebo uložit konfiguraci externí CA libovolné CA zadáním jejího id, včetně CA jiné organizace. Routy jsou odstraněny; konzole a klienti používají POST /api/v1/ca/{id}/hsm a POST /api/v1/ca/{id}/external/configure. Tyto routy kontrolují, že CA patří do organizace volajícího (viz „Routy certifikačních autorit zůstávají v organizaci volajícího“).
Role přiřazená jedné organizaci už nedosáhne na projekty jiné — Kontrola oprávnění projektové routy (/api/v1/projects/{id}/... a rout, které pojmenují certifikát nebo jiný zdroj patřící projektu; routy /api/v1/ca/{id} pojmenují CA a tato změna je nepokrývá, řeší je „Routy certifikačních autorit zůstávají v organizaci volajícího“) posuzovala vlastní organizaci volajícího (výchozí organizaci u relace konzole nebo API tokenu) a nikdy organizaci projektu, takže administrátor přiřazený jedné organizaci mohl podle id číst a měnit CA, certifikáty a další zdroje projektu jiné organizace. Oprávnění nyní musí platit i v organizaci projektu; role neomezené na organizaci a požadavky uvnitř jedné organizace se nemění.
Fronta obnov se posuzuje v projektu a prostředí certifikátu — Fronta obnov (/api/v1/renewal-queue/…) a endpointy obnovení a historie obnov certifikátu kontrolovaly oprávnění bez projektu a prostředí certifikátu: role omezená na jeden projekt dostala 403 u každé položky fronty a role omezená na dev mohla číst, rušit, obnovovat a znovu spouštět položky a certifikáty prostředí prod. Položka fronty nyní patří do projektu svého certifikátu: schválení, zrušení, obnovení běhu a DCV endpointy vyžadují své oprávnění v tomto projektu, v prostředí certifikátu (a v organizaci projektu), POST /api/v1/certificates/{id}/renew a GET …/renewal-history ho vyžadují v projektu a prostředí samotného certifikátu a GET /api/v1/renewal-queue/ ponechává položky, jejichž certifikát smí uživatel číst. Certifikát bez projektu se posuzuje přísně (dosáhne na něj jen role, která není omezená na některé projekty); neznámou položku fronty dál odpoví samotný endpoint.
Kontrola organizace se týká i smazaných projektů — Kontrola, že role přiřazená jedné organizaci nedosáhne na projekty jiné, četla organizaci projektu běžným dotazem, který přeskakuje projekt smazaný (měkce, jako DELETE /api/v1/projects/{id}), takže CA, certifikáty a další data, která smazaný projekt jiné organizace stále drží, byly pro administrátora výchozí organizace dostupné podle id. Organizace se nyní čte včetně smazaných projektů a požadavek se odmítne, pokud ji nelze přečíst; odmítnuté rozhodnutí se ukládá do cache stejně jako povolené.
Seznam projektů ukazuje jen projekty organizace volajícího — GET /api/v1/projects/ vracel uživateli, jehož role je přiřazena organizaci, všechny projekty všech organizací, protože se role počítala jako držená „všude“ a seznam se nefiltroval. Projekt jiné organizace než té z požadavku se nyní kontroluje zvlášť, takže takový uživatel vidí jen projekty své organizace; role neomezená na organizaci dál vypíše všechny.
Routy certifikačních autorit zůstávají v organizaci volajícího — GET a PUT /api/v1/ca/{id}, POST /api/v1/ca/{id}/hsm, …/external/configure, …/external/test, …/external/templates/sync a …/crl/regenerate nekontrolovaly, ke které organizaci CA patří, takže administrátor přiřazený jedné organizaci mohl podle id přečíst CA jiné organizace, přepsat jí nastavení HSM, adresy OCSP a CRL, uložit pro ni konfiguraci externí CA a znovu vygenerovat její CRL, a GET /api/v1/ca/ vypisoval CA všech organizací. CA patří do organizace svého projektu nebo CA účtu, ke kterému je připojena. Tyto routy teď vyžadují oprávnění v této organizaci (přiřazení, které není omezeno na organizaci, dosáhne na každou CA) a odpovídají 403 Access denied pro CA jiné organizace, pro CA, která nepatří žádné organizaci (vytvořenou přes POST /api/v1/ca/initialize: dosáhne na ni jen přiřazení neomezené na organizaci) a pro id, které žádnou CA nepojmenovává; ve všech třech případech stejně, aby nešlo zjišťovat id. Seznam vrací jen CA, které volající smí číst. Zkontrolujte přiřazení rolí API tokenů, které používají /api/v1/ca/: token s ca:admin omezeným na jednu organizaci už nedosáhne na CA, které nepatří žádné organizaci.
Šablony certifikátů zůstávají v organizaci volajícího — GET, PUT a DELETE /api/v1/certificate-templates/{id} nekontrolovaly, ke které organizaci šablona patří, takže administrátor přiřazený jedné organizaci mohl podle id přečíst, změnit nebo smazat šablonu jiné organizace (změna šablony navíc mění nastavení obnovy certifikátů, které šablonu následují). Oprávnění se teď posuzuje v organizaci šablony; šablona jiné organizace i neznámé id odpoví 403. Čtení šablon (GET /api/v1/certificate-templates/ a /{id}) je nově otevřené i roli přiřazené jednomu projektu, pro šablony její vlastní organizace, protože je potřebuje záložka Šablony projektu a dialog žádosti o certifikát: taková role dostávala na seznam 403. Šablony jiné organizace vyžadují přiřazení této organizace nebo přiřazení neomezené na organizaci.
Šablony projektů zůstávají ve své organizaci a už nepřepisují jiné šablony certifikátů — PUT /api/v1/organizations/templates/{templateId} brala propojenou šablonu certifikátu z protocol_config.certificate_template_id požadavku a tuto šablonu přepsala, takže držitel template:write mohl přepsat šablonu certifikátu jiné organizace nebo sdílenou systémovou šablonu (název, platnost, použití klíče, schvalování, CA účet; s ní se měnilo i nastavení obnovy všech certifikátů, které ji následují), a obě routy měnily nebo mazaly šablonu projektu libovolné organizace. Propojení teď nastavuje jen server: certificate_template_id z požadavku se ignoruje a uložené propojení na šablonu jiné organizace nebo systémovou šablonu se nenásleduje (šablona projektu se místo toho propojí se šablonou své organizace). Úprava a DELETE posuzují oprávnění v organizaci šablony a pro šablonu jiné organizace odpoví 403 (stejně pro neznámé id, kromě role neomezené na organizaci, která dostane 404; dříve obojí 500). Vytvoření a úprava šablony projektu kategorie certifikátů teď kontroluje CA účet a produkt stejně jako routy šablon certifikátů (400 pro účet nebo produkt jiné organizace, 409 pro kód obsazený systémovou šablonou).
Šablona bez CA vydává jen z interní CA své organizace — Když šablona certifikátu neuváděla CA účet ani CA, vydání podepsala ta aktivní interní CA, kterou databáze vrátila jako první, což mohla být interní CA jiné organizace. Taková šablona teď vydává jen z interní CA své organizace (organizace šablony, tedy projektu) (certifikát si zapíše tento CA účet); bez ní se požadavek odmítne s 400 („template has no CA assigned and the organization has no internal CA“). Systémové šablony jako agent-mtls dál používají aktivní interní CA.
Objevené certifikáty vyžadují přiřazení neomezené na organizaci a archivované certifikáty se vypisují podle organizace a prostředí — Objevené certifikáty nemají organizaci (jeden záznam na otisk, bez ohledu na to, agent nebo CA účet které organizace jej nahlásil), přesto role přiřazená jedné organizaci vypisovala, četla, ignorovala, archivovala, přiřazovala a adoptovala objevené certifikáty všech organizací. Routy /api/v1/discovered-certificates teď roli omezené na organizaci nebo projekt odpoví 403; role bez těchto omezení (omezení na prostředí zůstává) funguje jako dřív, takže ji přiřaďte uživatelům, kteří objevené certifikáty třídí. GET /api/v1/archived/certificates a certifikáty v GET /api/v1/archived/summary vypisovaly archivované certifikáty všech organizací a prostředí; teď ponechají jen ty, které volající smí číst (archive:read) v projektu, organizaci a prostředí certifikátu, a přehled ukazuje archivované objevené certifikáty jen roli neomezené na organizaci nebo projekt.
Export certifikátu vrací 404 pro neznámý certifikát a už neposílá text chyby — GET /api/v1/certificates/{id}/export odpovídal pro neznámý certifikát 500 "record not found" a u jiných selhání posílal interní text chyby (například failed to parse certificate: x509: …). Neznámý certifikát teď odpoví 404 "Certificate not found"; formát, který může volající změnit (DER s include_chain, JKS bez privátního klíče, nepodporovaný formát), odpoví 400 se zprávou (dříve 500); každé jiné selhání odpoví pevným Internal server error a příčina se zapíše jen do logu serveru.
Agentní mTLS ověřuje řetězec klientského certifikátu — POST /api/v1/agents/me/refresh-token a starší stahování aktualizací agenta přijímaly jakýkoli klientský certifikát (na TLS spojení nebo v hlavičce X-Client-Cert / ssl-client-cert důvěryhodné proxy), jehož sériové číslo odpovídalo certifikátu agenta, bez ověření, kdo jej podepsal, takže self-signed certifikát s tímto sériovým číslem získal nový token agenta. Certifikát teď musí být certifikát agenta, který MazeVault pro toto sériové číslo vydal (stejný SHA-256 otisk), nesmí být zneplatněný, musí být právě platný, povolený pro ověření klienta a navazovat na CA, která jej vydala (CA zapsanou u certifikátu; u certifikátů zapsaných dříve, než se CA zapisovala, na některou z interních CA). Jakýkoli jiný certifikát dostane 401 CLIENT_CERT_INVALID bez podrobností (prošlý dříve dostal CERT_EXPIRED); důvod se zapíše do logu. Nasazení agenti fungují dál bez nové registrace: jejich certifikáty vydala interní CA a jsou zapsané. Agenta, jehož vydávající CA byla smazána, je nutné zaregistrovat znovu.
Synchronizace nasazení certifikátu se posuzuje ve vlastním prostředí certifikátu a jen pro jeho cíl — POST /api/v1/certificates/{id}/targets/{targetId}/sync posuzovalo rotation:execute jen v prostředí, které uvedl klient, a certifikát v cestě nebralo v úvahu, takže uživatel omezený na dev nasadil certifikát z prod do jeho cíle tím, že poslal ?environment=dev, a libovolný cíl šlo synchronizovat pod id libovolného certifikátu. Cíl nyní musí patřit certifikátu v cestě (jinak 404) a synchronizace se posuzuje v prostředí a projektu tohoto certifikátu, stejně jako kanonické POST /api/v1/rotation/resources/certificate_deployment/{id}/trigger; obě cesty běží stejným kódem. Neúspěšná synchronizace vrací pevné tělo „Internal server error“ místo textu chyby kroku a zapisuje se do auditu s výsledkem outcome=failed.
Rotační cesty certifikátu se posuzují ve vlastním prostředí certifikátu — Způsobilost, rotační konfigurace, historie, běhy, předběžné kontroly obnovy a nasazení, cíle nasazení a náhled formátu pod /api/v1/certificates/{id}/… posuzovaly oprávnění v prostředí, které uvedl klient, takže uživatel omezený na dev četl a měnil rotační konfiguraci a cíle nasazení certifikátu z prod tím, že poslal ?environment=dev. Každá cesta nyní posuzuje oprávnění v prostředí a projektu certifikátu v cestě a neexistující certifikát vrací 404 „Certificate not found“ (konfigurace, předběžná kontrola a vytvoření cíle vracely 500 s chybou databáze, historie prázdný seznam).
Cíle a běhy certifikátu jsou dostupné jen pod tímto certifikátem a cíl doručující do jiného projektu se posuzuje i tam — GET, PUT, DELETE /api/v1/certificates/{id}/targets/{targetId} a GET …/status nebraly v úvahu certifikát v cestě, takže uživatel, který smí pracovat s jedním certifikátem, četl, měnil nebo mazal cíl nasazení libovolného jiného certifikátu, a GET /api/v1/certificates/{id}/rotation/executions/{execId} vracelo libovolný běh. Cíl či běh nyní musí patřit certifikátu v cestě (jinak 404). Cíl dostává certifikát i jeho soukromý klíč, proto jeho vytvoření či změna nově vyžaduje také secret:write tam, kam doručuje, pokud to není vlastní projekt a prostředí certifikátu: u integrace (integration_id) v projektu a prostředí integrace; u cíle správce tajných klíčů v projektu a prostředí, do kterého doručení zapisuje (target_project_id a environment z konfigurace integrace, jinak target_project_id a target_environment cíle, jinak production), a u target_secret_id také ve vlastním projektu a prostředí tohoto tajného klíče.
Cíl rotace tajného klíče doručuje jen agentovi projektu tajného klíče — Cíl nasazení tajného klíče (POST, PUT /api/v1/secrets/{id}/rotation/targets…), jehož config.agent_id uváděl libovolného agenta, i agenta jiné organizace, se přijal s oprávněním secret:rotate na tajný klíč a každá rotace pak novou hodnotu tajného klíče tomuto agentovi odeslala. Agent nyní musí být navázán na vlastní projekt tajného klíče (aktivní integrace agenta v projektu), jinak vytvoření i úprava vracejí 404. Dříve vytvořené cíle se znovu kontrolují při běhu rotace: krok synchronizace k agentovi, který na projekt tajného klíče navázán není, selže, nic neodešle a odmítnutí zapíše do logu (nikdy hodnotu).
Cíl tajného klíče zapisující do jiného prostředí projektu se posuzuje v tomto prostředí — Cíl nasazení tajného klíče, který uváděl integraci vlastního projektu tajného klíče v jiném prostředí (binding_ref nebo config.integration_id, například integraci z prod pro tajný klíč z dev), vyžadoval jen secret:rotate na tajný klíč, takže rotátor omezený na dev zařídil, aby každá rotace zapisovala do prod. Takový cíl nyní vyžaduje také secret:write v prostředí integrace (jinak 403), stejně jako už cíl uvádějící integraci jiného projektu.
Historie, kontrola souladu a import objevených keytabů zůstávají v organizaci volajícího — GET /api/v1/keytabs/{id}/history, POST /api/v1/keytabs/{id}/check-compliance a POST /api/v1/keytabs/discovered/{id}/import neporovnávaly keytab s organizací volajícího: kdokoli s oprávněním keytab:read nebo keytab:write mohl číst historii verzí keytabu jiné organizace, spustit jeho kontrolu souladu nebo z jeho objeveného keytabu vytvořit keytab v této organizaci. Stejně jako get, update, download a delete nově odpovídají 404 pro keytab či objevený keytab jiné organizace i pro neznámé id (historie neznámého keytabu byla prázdný seznam). API token uvádí svou organizaci v organization_id na těchto cestách stejně jako na ostatních.
Stažení keytabu vrací Cache-Control: no-store — GET /api/v1/keytabs/{id}/download je záměrné odhalení uloženého keytabu chráněné oprávněním (zůstává auditované, nikdy s hodnotou). Odpověď nově nese pouze Cache-Control: no-store, takže keytab neuloží žádný prohlížeč ani proxy; OpenAPI dokument a generovaný klient hlavičku popisují.
Selhání auditních logů, compliance reportu a exportu do Terraformu už neposílají interní text chyby — POST /api/v1/audit-logs/search, GET /api/v1/audit-logs/, GET /api/v1/projects/{id}/audit-logs, GET /api/v1/compliance/{type} a GET /api/v1/terraform/export/project|organization/{id} při selhání databáze nebo služby vracely text chyby v těle HTTP 500. Nově vracejí pevný text Internal server error; příčina se zapisuje pouze do logu serveru.
Export organizace do Terraformu kontroluje organizaci z URL — GET /api/v1/terraform/export/organization/{id} posuzovala oprávnění org:read jen pro organizaci požadavku, takže uživatel omezený na jednu organizaci mohl podle id exportovat libovolnou jinou. Id se nyní ověřuje proti přiřazením organizací volajícího (403 pro jinou organizaci).
Test integrace organizace už nedešifruje hodnoty z požadavku — POST /api/v1/organizations/{id}/integrations/test před odesláním testovacího oznámení dešifroval každou hodnotu enc: z požadavku hlavním klíčem serveru, takže držitel integration:read mohl poslat uložený šifrový text (například api_token Jiry s vlastní base_url) a získat otevřený text na hostiteli dle své volby. Endpoint už vstup z požadavku nedešifruje: konfigurace s hodnotou enc: odpoví 400 invalid integration config a nic se neodešle.
Integrace organizace už nevracejí uložená tajemství — GET /api/v1/organizations/{id}/integrations vracel dešifrované přihlašovací údaje všech integrací (API token Jiry, URL Teams/Slack/webhooku, client secret Office 365) a otevřené přihlašovací údaje streamů logů a archivů (HEC token Splunku, API klíč a heslo Elasticsearch, tajný přístupový klíč S3, klíč účtu, SAS token a connection string Azure Blob, heslo sdílené složky); POST /api/v1/organizations/{id}/integrations a PUT /api/v1/organizations/integrations/{integrationId} vracely šifrované hodnoty. Tato pole nyní odpovídají ********, jsou-li nastavena, a "", jsou-li prázdná. Úprava, která pošle zpět ******** nebo tajné pole vynechá, zachová uloženou hodnotu; "" vymaže volitelné tajemství a povinné zachová (Jira api_token, Teams/Slack webhook_url, webhook url, Splunk hec_token, S3 secret_access_key).
Úprava a smazání integrace organizace ověřují organizaci integrace — PUT a DELETE /api/v1/organizations/integrations/{integrationId} posuzovaly integration:write jen pro organizaci požadavku, takže uživatel omezený na jednu organizaci mohl podle id měnit nebo mazat notifikační kanály, streamy logů a archivy jiné organizace. Nyní se organizace integrace ověřuje vůči přiřazením volajícího (403 pro jinou organizaci).
URL integrací odmítají IPv6 loopback — Kontrola SSRF u URL integrací organizace (Jira, Teams, Slack, webhook) porovnávala hostitele s [::1], což rozparsovaná URL nikdy nevrátí, takže http://[::1]/… prošla a testovací oznámení nebo report mohly jít na službu na samotném serveru. ::1 je nyní odmítnuta stejně jako 127.* a localhost.
Selhání týdenního reportu už neposílají interní text chyby — POST /api/v1/reports/trigger a GET /api/v1/reports/preview odpovídaly na selhané doručení nebo volání databáze textem chyby v details těla HTTP 500, včetně cílových hostitelů (například dešifrované URL webhooku) a příjemců. Nyní odpovídají Failed to trigger report / Failed to generate preview bez details; příčina se zapisuje jen do logu serveru.
URL integrací odmítají lokální IP adresy v každém zápisu — Kontrola SSRF u URL integrací organizace (Jira, Teams, Slack, webhook) porovnávala IP hostitele jako text, takže jiné zápisy lokální adresy prošly ([0::1], [0:0:0:0:0:0:0:1], [::ffff:127.0.0.1], [::], [fe80::1%eth0]). Hostitel se nyní parsuje jako IP (bez závorek a zóny) a v jakémkoli zápisu se odmítají adresy loopback (127.0.0.0/8, ::1), nespecifikované (0.0.0.0, ::), link-local (169.254.0.0/16 včetně adresy cloudových metadat 169.254.169.254, fe80::/10) a multicast, stejně jako localhost a prázdný hostitel. Privátní rozsahy (172.16.0.0/12, fd00::/8) a jména hostitelů, která se překládají na interní adresy, tato kontrola neodmítá.
URL integrací odmítají localhost. a *.localhost — Kontrola SSRF u URL integrací organizace přijímala localhost. (s tečkou na konci) a jména pod .localhost (například api.localhost), která se překládají na samotný server. Obojí je nyní odmítnuto stejně jako localhost.
Přihlašovací údaje streamů logů a archivů jsou v klidu šifrované — HEC token Splunku, API klíč a heslo Elasticsearch, tajný přístupový klíč S3, klíč účtu, SAS token a connection string Azure Blob a heslo sdílené složky u integrací organizace byly v databázi uloženy v otevřené podobě (šifrované byly jen přihlašovací údaje notifikací). Nyní se šifrují hlavním klíčem serveru stejně jako ostatní. Existující záznamy nepotřebují migraci: dál se čtou tak, jak jsou, a zašifrují se při své příští úpravě.
Zachované tajemství integrace nelze přesunout na jiný endpoint — PUT /api/v1/organizations/integrations/{integrationId} zachoval uložené tajemství poslané zpět jako ******** (nebo vynechané) i tehdy, když tentýž požadavek změnil, kam se posílá, takže držitel integration:write mohl nasměrovat base_url Jiry, endpoint Splunku, endpoints/cloud_id Elasticsearch, bucket/region/endpoint S3, account_name/container_name Azure Blob, base_path sdílené složky nebo tenant_id/client_id Office 365 na vlastního hostitele a získat uložený přihlašovací údaj. Taková úprava nyní odpoví 400 invalid integration config a nic nezmění; při změně endpointu zadejte tajemství znovu.
Test uložené integrace organizace funguje s maskovanými tajemstvími — Protože se tajemství vracejí jako ********, POST /api/v1/organizations/{id}/integrations/test a .../test-archive přijímají volitelné integration_id uložené integrace (stejného typu): tajná pole poslaná jako ******** nebo vynechaná se převezmou z ní, pokud se nezměnila pole endpointu (URL, hostitel, účet, bucket, cesta); změněný endpoint vyžaduje znovu zadat tajemství (400 invalid integration config). Uložená integrace se posuzuje ve své organizaci (403 pro jinou organizaci, 404 pro neznámou). Neúspěšný test uložené integrace odpoví integration test failed (test archivu: Connection failed) místo chyby poskytovatele, která mohla obsahovat uloženou URL webhooku; příčina se zapisuje do logu.
Neúspěšné testy uložené integrace už nezapisují do logu její tajnou URL — Záznam v logu serveru o neúspěšném …/integrations/test nebo …/test-archive uložené integrace (integration_id) obsahoval chybu poskytovatele, která cituje uloženou URL Slacku, Teams nebo webhooku; nyní URL vynechává a každou uloženou tajnou hodnotu maskuje.
Čtení integrace projektu už nevrací uložená tajemství — GET /api/v1/projects/integrations/{integrationId} vracel dešifrovanou konfiguraci: tokeny Vaultu, klientská tajemství (včetně klientského tajemství jednotného přihlášení Entra ID zkopírovaného do integrací on-behalf-of), hesla a klíče a jako password i hodnotu propojeného tajemství, a to každému držiteli integration:read, který tak mohl číst tajemství bez secret:read. Každé vyplněné tajné pole nyní vrací ********, včetně hodnoty propojeného tajemství. PUT téže integrace u tajného pole odeslaného jako ******** nebo vynechaného ponechá uloženou hodnotu, ale jen pokud se nemění pole endpointu (URL, hostitelé, porty, tenant, region, nastavení TLS); změna endpointu se zachovaným tajemstvím vrací 400 invalid integration config a nic nemění. Uložený formulář už do konfigurace nekopíruje hodnotu propojeného tajemství.
Cesty integrací projektu ověřují prostředí integrace — Cesty podle ID integrace (GET, PUT, DELETE /api/v1/projects/integrations/{integrationId} a její cesty deletion-impact, test, sync a sessions) posuzovaly integration:read / integration:write v prostředí požadavku, takže uživatel s oprávněním jen pro dev mohl číst, měnit, testovat, synchronizovat nebo smazat integraci prod. Nyní se posuzují ve vlastním prostředí a projektu integrace (jinak 403) a neznámé ID vrací 404 integration not found místo 500. GET /api/v1/projects/{id}/integrations/grouped vypisuje jen prostředí, která uživatel smí číst, GET /api/v1/projects/{id}/environments/{env}/integrations se posuzuje v {env} a POST /api/v1/projects/{id}/integrations/test-connection v prostředí z těla požadavku.
Test uložené integrace projektu funguje s maskovanými tajemstvími — Protože se tajemství integrace projektu vracejí jako ********, POST /api/v1/projects/{id}/integrations/test-connection přijímá volitelné integration_id uložené integrace (stejný projekt a poskytovatel): tajná pole odeslaná jako ******** nebo vynechaná se převezmou z ní, pokud se nezměnila pole endpointu; změněný endpoint vyžaduje tajemství zadat znovu (400 invalid integration config). Uložená integrace se posuzuje s integration:write ve svém prostředí a projektu (403, 404 pro neznámou). Chybová zpráva takového testu maskuje uložené tajné hodnoty.
Chyby integrací projektu už neposílají interní text chyby — Cesty databázových relací (GET …/sessions, POST …/sessions/terminate, POST …/sessions/drain u /api/v1/projects/integrations/{integrationId}), test připojení, ruční synchronizace a seznamy integrací vracely při selhání služby nebo databáze text chyby v těle HTTP 500. Nyní vracejí Internal server error; příčina se zapisuje jen do logu serveru. Neplatné ID integrace u GET, PUT, DELETE /api/v1/projects/integrations/{integrationId} a jejího deletion-impact vrací 400 Invalid Integration UUID a tělo úpravy ve špatném tvaru 400 s chybou vazby, místo 500.
Odkazy na tajemství v databázových integracích vyžadují oprávnění číst tajemství — Databázová integrace může heslo administrátora nebo walletu uvést odkazem (_password_source mazevault nebo keyvault); server ho vyřeší a hodnotu pošle na databázového hostitele z konfigurace. Držitel integration:write bez secret:read tak mohl přes POST /api/v1/projects/{id}/integrations/test-connection nechat poslat libovolné tajemství projektu na hostitele dle své volby, takový odkaz uložit při vytvoření nebo úpravě, nebo ho vyřešit cestami test, sync a sessions; zdrojová integrace správce tajemství byla přijata z libovolného projektu i organizace. Požadavek nyní odkaz vyřeší nebo uloží jen tehdy, když volající má secret:read v projektu a prostředí odkazovaného tajemství a u zdrojové integrace integration:read a secret:read v jejím vlastním projektu a prostředí (jinak 403); odkaz v testu připojení bez environment vrací 400. Plánované synchronizace uložených integrací řeší odkazy jako dosud. Neúspěšné vytvoření databázové integrace (například duplicitní název) už nekončí pádem serveru.
Úprava integrace projektu nepřesune heslo administrátora ani propojené tajemství na jiného hostitele — Pravidlo, že zachované tajemství nesmí následovat změněný endpoint, pokrývalo jen tajemství uvnitř konfigurace. PUT /api/v1/projects/integrations/{integrationId} mohl změnit host nebo port databázové integrace při zachování uloženého hesla administrátora, nebo endpoint integrace, jejíž přihlašovací údaj pochází z propojeného tajemství, a další volání test nebo cesty relací poslalo toto heslo nebo hodnotu tajemství na nového hostitele. Taková úprava nyní vrací 400 invalid integration config a nic nemění: endpoint databázové integrace se mění jen se znovu zadaným admin_password a integrace s propojeným tajemstvím si endpoint ponechává.
Test uložené integrace projektu maskuje uložená tajemství v textu chyby — POST /api/v1/projects/integrations/{integrationId}/test vracel při neúspěchu text chyby poskytovatele a ukládal ho jako last_sync_error integrace; poskytovatel, který cituje obdržený přihlašovací údaj (token, heslo v připojovacím řetězci), tak uložené tajemství ukázal každému s integration:read. Každá uložená tajná hodnota je v tomto textu nyní nahrazena ********.
Zachované tajemství integrace projektu nelze směrovat přes jiného agenta — PUT /api/v1/projects/integrations/{integrationId} mohl přepnout use_agent_proxy nebo změnit agent_id při zachování uložených tajemství a poslat je přes agenta zvoleného volajícím. Směrování přes agenta se nyní počítá jako endpoint: jeho změna se zachovaným uloženým tajemstvím vrací 400 invalid integration config; pro změnu tajemství zadejte znovu.
Další pole integrace projektu se počítají jako endpoint — Region AWS (aws_region, region) a nastavení síťového šifrování Oracle (use_nne, encryption_level, encryption_types, checksum_level, checksum_types) se nyní počítají jako pole endpointu: úprava integrace projektu, která je mění při zachování uloženého tajemství, vrací 400 invalid integration config.
Trasy skupin integrací už nevracejí text databázové chyby — Selhávající GET nebo POST /api/v1/projects/{id}/integration-groups a GET, PUT nebo DELETE /api/v1/integration-groups/{id} odpovídaly HTTP 500 s původní chybou databáze (tabulka, omezení a SQL stav). Nyní odpovídají {"error": "Internal server error"}; příčina je jen v logu serveru.
Skupiny integrací propojují jen integrace vlastního projektu — mappings skupiny integrací (POST /api/v1/projects/{id}/integration-groups, PUT /api/v1/integration-groups/{id}) se ukládala bez kontroly id integrací, takže skupina mohla uvést integraci jiného projektu nebo organizace, kterou její vlastník nesmí číst. Každé mapování musí nyní uvádět integraci projektu skupiny; chybné, neznámé nebo cizí id vrací 400 mappings must name integrations of the project a nic se nezmění. Čtení, změna a smazání skupiny podle id a výpis či vytvoření skupin projektu se posuzují ve vlastním projektu a organizaci skupiny.
Aktualizace databázové integrace posuzuje reference na tajemství v konfiguraci — PUT /api/v1/projects/integrations/{integrationId} databázové integrace uložil referenci v konfiguraci (heslo Oracle walletu, _wallet_password_source mazevault nebo keyvault), aniž by ověřil, že volající smí referencované tajemství číst, zatímco vytvoření to ověřovalo. Držitel integration:write bez secret:read tak mohl nechat tajemství odeslat na databázový server při dalším připojení. Aktualizace nyní posuzuje reference zapsané konfigurace stejně jako vytvoření (403 bez secret:read v projektu a prostředí referencovaného tajemství).
Kontrola Managed Identity zahrnuje jen organizaci požadavku — POST /api/v1/admin/azure/mi-permissions-check testovala integrace Azure všech organizací a vracela jejich názvy, URL Key Vaultů a prostředí držiteli integration:write v kterékoli z nich. Nyní vypisuje a testuje jen integrace projektů organizace požadavku.
Incident se čte jen v rámci vlastní organizace — GET /api/v1/incidents/{id} vracel jakýkoli incident podle id, i incident jiné organizace. Incident se nyní posuzuje tam, kam patří: role omezená na organizaci dostane pro incident jiné organizace 403 a prostředí a projekt incidentu se kontrolují jako u trasy pro vyřešení. Neznámé id dál vrací 404; selhání databáze nyní vrací 500 {"error": "Internal server error"} místo 404.
Skrytí řádku rotace vyžadující pozornost zůstává v rámci organizace — POST /api/v1/dashboard/rotation/actionable/{id}/dismiss zapsal skrytí do prostředku rotace kterékoli organizace podle id. Prostředek projektu se nyní posuzuje tam, kam patří: role omezená na organizaci dostane pro prostředek projektu jiné organizace 403 a nic se nezapíše, a dashboard:write musí platit i v prostředí a projektu prostředku.
Reporty certifikátů a seznam incidentů už nevracejí text databázové chyby — Selhávající GET /api/v1/dashboard/certificates/reports, POST /api/v1/dashboard/certificates/refresh nebo GET /api/v1/incidents/ odpovídaly HTTP 500 s původní chybou databáze. Nyní odpovídají {"error": "Internal server error"}; příčina je jen v logu serveru.
Platformní řádky rotací na přehledu vyžadují neomezenou roli — GET /api/v1/dashboard/rotation/actionable zobrazoval řádky rotací bez projektu (systémové klíče, servisní identity, SSH páry klíčů bez projektu) rolím omezeným na organizaci a POST /api/v1/dashboard/rotation/actionable/{id}/dismiss jim je dovolil skrýt. Stejně jako u tras Rotation Problems se takové řádky nyní zobrazují jen roli neomezené na projekt ani organizaci a skrytí jinou rolí vrací 403 a nic nezapíše.
Vytvoření projektové integrace a vazby agentů kontrolují prostředí — POST /api/v1/projects/{id}/integrations a POST /api/v1/projects/{id}/integrations/agents posuzovaly integration:write v prostředí požadavku, ne v environment těla, takže uživatel s oprávněním jen v dev mohl vytvořit integraci nebo navázat agenta v prod. GET /api/v1/projects/{id}/integrations/agents vracel vazby všech prostředí a DELETE /api/v1/projects/{id}/integrations/agents/{agentId} odebral vazbu v jakémkoli prostředí. Vytvoření a navázání se nyní posuzují v prostředí těla, seznam ponechává vazby prostředí, kde má uživatel integration:read (a vazby bez prostředí), a odebrání vazby se posuzuje v jejím vlastním prostředí (jinak 403 a nic se nezmění). Odebrání agenta, kterého projekt nemá navázaného, vrací 404 místo 204.
Rozsah Entra integrace se posuzuje tam, kam integrace patří — GET a PUT /api/v1/entra/{integrationId}/scope četly a nahrazovaly rozsah Entra kterékoli integrace podle id, i integrace jiného prostředí, projektu nebo organizace, a entra:read / entra:write posuzovaly jen v prostředí požadavku. Nyní se posuzují ve vlastním prostředí a projektu integrace (jinak 403 a nic se nezmění) a neznámé id vrací 404 integration not found místo 400 s textem databáze. POST /api/v1/entra/projects/{id}/scope-preview se posuzuje v environment svého těla.
Agenta lze navázat jen na projekty vlastní organizace — POST /api/v1/projects/{id}/integrations/agents navázal na projekt agenta kterékoli organizace a navázaný agent s allow_deployment dostává nasazení projektu. Agent registrovaný v jiné organizaci, než je organizace projektu, je nyní odmítnut s 404 Agent not found jako neznámý agent a nic se nezapíše. Agenti registrovaní dříve, než agenti nesli organizaci, zůstávají navázatelní.
Trasy rozsahu Entra už nevracejí interní text chyby — GET a PUT /api/v1/entra/{integrationId}/scope, POST /api/v1/entra/projects/{id}/scope-preview a krok rozsahu Entra v POST /api/v1/projects/{id}/integrations odpovídaly na každé selhání 400 s textem chyby, včetně selhání databáze, dešifrování nebo Microsoft Graph. Vstup, který může volající opravit (integrace jiného poskytovatele, neúplná nebo nepodporovaná vazba, neúplné přihlašovací údaje náhledu), dál vrací 400 se zprávou; jakékoli jiné selhání nyní vrací 500 {"error": "Internal server error"} a příčina je jen v logu serveru.
Heslo peněženky databáze se musí při změně zdroje zadat znovu — PUT /api/v1/projects/integrations/{integrationId} databázové integrace mohl změnit _wallet_password_source (static, mazevault, keyvault) nebo _wallet_password_source_integration_id, zatímco wallet_password chybělo nebo bylo poslané jako ********; uložená hodnota pak zůstala pod novým zdrojem, takže cesta v key vaultu se stala statickým heslem peněženky, nebo se skutečné heslo vyhodnotilo jako klíč tajemství a objevilo se v chybě synchronizace. Taková úprava nyní vrací 400 wallet_password must be re-entered when its source changes a nic nezmění; úprava, která pošle novou hodnotu, se uloží, a výslovně prázdné wallet_password uložené heslo vymaže (například když integrace Oracle přejde z TCPS na síťové šifrování a peněženku už nepoužívá). Pro heslo správce to platilo už dříve.
Chyby synchronizace integrace maskují hodnoty tajemství — POST /api/v1/projects/integrations/{integrationId}/sync a běhy synchronizace a testu připojení, které zapisují stav synchronizace projektové integrace, ukládaly a vracely text chyby beze změny v last_sync_error a ve zprávě synchronizace. Neúspěšný odkaz na tajemství cituje hodnotu, kterou se pokusil vyhodnotit (například MazeVault secret "…" not found), takže heslo uložené pod nesprávným zdrojem se mohlo objevit tam i v logu serveru. Každá hodnota tajemství z konfigurace integrace (uložená i vyhodnocená) je v tomto textu nyní nahrazena ********, i tam, kde ji text cituje s escapovanými " a \; tato escapovaná podoba se nyní maskuje i v textu chyby testů připojení projektové integrace. Stejné maskování platí pro všechny ostatní zápisy last_sync_error projektové integrace: pravidla synchronizace, synchronizaci Entra ID a kroky rotace, které zapisují selhání integrace.
Kontakty pro incidenty vyžadují oprávnění organizace — GET a PUT /api/v1/organization/incident-contacts vyžadovaly jen přihlášení, takže kterýkoli uživatel nebo API token mohl číst kontakty organizace pro incidenty (jména, e-mailové adresy, telefony) a nahradit je, a tím přesměrovat oznámení o incidentech. Čtení nyní vyžaduje org:read a nahrazení org:admin; bez nich trasy vracejí 403 a nic se nezmění. Záložka Incident Response v nastavení organizace se zobrazuje jen s org:read a její úpravy jen s org:admin.
Koncové body streamů logů a archivů odmítají lokální adresy — Kontrola SSRF integrací organizace pokrývala jen URL notifikací (Jira, Teams, Slack, webhook). endpoint Splunku, každá položka endpoints Elasticsearch, host syslogu a hostitel Azure Blob (z account_name nebo z BlobEndpoint či AccountName/EndpointSuffix connection stringu) se nekontrolovaly, takže stream auditu se svým HEC tokenem nebo přihlašovacími údaji šlo nasměrovat na službu na samotném serveru nebo na adresu cloudových metadat. POST /api/v1/organizations/{id}/integrations, PUT /api/v1/organizations/integrations/{integrationId} a POST /api/v1/organizations/{id}/integrations/test-archive nyní odmítají adresy loopback (127.0.0.0/8, ::1), nespecifikované, link-local (169.254.0.0/16 včetně 169.254.169.254, fe80::/10) a multicast v jakémkoli zápisu, localhost a jména pod .localhost s 400 a zprávou kontroly; nic se neuloží ani nevolá. Privátní rozsahy (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) zůstávají pro tyto koncové body povolené.

Poznámky¶

Dopad na upgrade (omezené role pro uživatele v prohlížeči) — Role omezené na prostředí a projekt nyní omezují i uživatele v prohlížeči: před upgradem zkontrolujte přiřazení rolí (Řízení přístupu). Uživatel, jehož přístup ve webovém rozhraní plynul z role přiřazené pro jedno prostředí nebo projekt, jej má nyní jen tam; kde má role platit všude, přiřaďte ji bez omezení. Uživatel, jehož role jsou všechny přiřazeny pro projekty, už nemá přístup k cestám bez projektu (správa uživatelů a rolí, nastavení organizace, vytváření projektů): přiřaďte potřebnou roli bez projektu nebo pro organizaci. Dokud nebudou jejich části webového rozhraní přepracovány, vracejí tyto cesty uživatelům a API tokenům omezeným na projekt (SDK, Terraform, CLI) 403 i s project_id: SSH klíče, keytaby, spravované tokeny, správa konfigurace, šablony rotace, zápis šablon certifikátů, inicializace CA, mapování skupin, dashboardy, reporty, incidenty a Azure discovery; routy objevených certifikátů vracejí 403 každé roli omezené na projekt nebo organizaci (viz „Objevené certifikáty vyžadují přiřazení neomezené na organizaci“). Seznam, analytika, import a CSR certifikátů přijímají roli omezenou na projekt v jejím projektu a prostředí a čtení šablon certifikátů přijímá roli přiřazenou kterémukoli projektu organizace šablony. Přesun certifikátu do jiného projektu (PUT /api/v1/certificates/{id}) vyžaduje oprávnění v obou projektech. Přiřazení rolí vytvořená Terraformem nebo Go SDK s project_id či environment před tímto vydáním jsou bez rozsahu: ta z Terraformu znovu aplikujte (terraform apply -replace=…), ta vytvořená přes Go SDK smažte a přiřaďte znovu. GET /api/v1/rbac/users/{id}/roles vypíše přiřazení uživatele; přiřazení bez project_id a environment platí všude. Každé chráněné zapisující tělo má nyní limit 16 MiB (nad ním 413), takže keytab může mít nejvýše 11 MB: MAZEVAULT_KEYTAB_MAX_SIZE_MB nad 11 se bere jako 11 (zapíše se varování). Uživatel přijde o zobrazenou roli, pokud všechna jeho přiřazení této role vypršela, nebo pokud byla zobrazená role vyšší než kterákoli přiřazená role (nebyla znovu synchronizována). Migrace 000216 (idempotentní, bez kroku zpět: odebrání přiřazení by odebralo přístup) přiřadí bez omezení: zobrazenou roli uživatelům bez jakéhokoli přiřazení; roli Viewer každému stávajícímu uživateli identity providera (LDAP, Entra ID, SAML/SCIM, GitHub, GitLab, OIDC), protože takoví uživatelé se nyní s ní vytvářejí, takže uživatel, jehož zobrazená role neměla oprávnění role Viewer (například Auditor nebo Finance; výchozí dashboard:read, system_output:read, entra:read), je získá; a jen pokud pak nikdo nemá roli admin bez omezení, roli admin každému uživateli se zobrazenou rolí admin. Dokud nikdo nemá roli admin bez omezení, server při startu zapíše varování. Když nikdo nemá roli admin bez omezení a někteří uživatelé se zobrazenou rolí admin mají vypršelé přiřazení role admin bez omezení, pojistka proti zamčení tato přiřazení znovu aktivuje a ostatní uživatelé se zobrazenou rolí admin nedostanou nic; jen když žádné takové vypršelé přiřazení neexistuje, dostane každý uživatel se zobrazenou rolí admin nové. Migrace také odvodí zobrazenou roli každého uživatele s přiřazeními z jeho přiřazení bez omezení (uživatelé jen s omezenými rolemi nyní ukazují Viewer). Tiše se zúží také: uživatel API tokenu, jehož přiřazení je omezené na jinou než výchozí organizaci, o ně přijde u každého požadavku; uživatel omezený na projekt neprojde kontrolami, které projekt nejmenují (export projektu, správa SSH klíčů, čtení záloh rotace, čtení integrací Key Vault); a rozhodnutí o oprávněních uložená v mezipaměti (Redis) před upgradem platí ještě až CACHE_PERMISSION_TTL_SECONDS (výchozí 5 minut), takže pro okamžité uplatnění nových pravidel tuto mezipaměť vyprázdněte (nebo tak dlouho počkejte). Stejná doba platí po přesunu zdroje do jiného projektu (certifikátu nebo šablony rotace): rozhodnutí uložená pro něj před přesunem platí, dokud nevyprší. Restart už nerozšiřuje přiřazení role admin účtu admin@mazevault.com omezené na prostředí nebo projekt.
Dopad na upgrade (efektivní řetězec, tělo z discovery, kontrakt nasazení přes agenta) — Verze 1.0.61 přidává jednu idempotentní, aditivní migraci 000199_discovered_certificate_body (certificate_pem, chain_pem TEXT NULL v discovered_certificates; health check databáze oba sloupce validuje). Do certificates se nepřidává žádný sloupec, neběží žádný backfill, žádný existující řetězec se nepřepisuje. Certifikáty, které už uložený řetězec mají, se exportují, zobrazují, rotují a nasazují byte po bytu stejně jako dosud (kryto regresním testem); chování se mění jen u certifikátů s prázdným řetězcem, a to pouze když v téže organizaci existuje ověřený vydavatel. Čtení (export, detail, seznam pro agenta) nikdy nic nepersistuje; dohledaný řetězec se zapíše jen tehdy, když import nebo adopce ukládá tělo certifikátu bez řetězce. API přírůstky jsou aditivní: chain_source, chain_complete, chain_warnings na GET /certificates/{id} (a /projects/{id}/certificates/{certId}); certificate_pem, chain_pem, chain_certificates na GET /discovered-certificates/{id}; export záznamu bez těla nyní vrací 422 CERTIFICATE_BODY_MISSING místo obecné 500. Terraform: data source mazevault_certificate získává chain_pem, chain_source, chain_complete; jeho certificate_pem je nyní naplněn (dříve byl vždy prázdný, protože SDK četlo pole, které API nevydává) — plány, které na něj odkazovaly, poprvé ukážou hodnotu. Změny chování k prověření: (1) import privátního klíče ke spravovanému certifikátu bez těla je odmítnut, dokud tělo neexistuje (připojí ho příští sken agenta, příští synchronizace s CA, nebo ruční import veřejného certifikátu — CRT/PEM/DER či PFX; agenti používající starý protokol /agents/me/discovery tělo nehlásí, takže záznamy objevené pouze jimi se doplní jednou ze zbývajících dvou cest); (2) cíle nasazení se validují při uložení i při sestavení workflow rotace: cíle WebLogic potřebují keystore_path, trust_store_password_ref při nastaveném trust_store_path a wlst_script_path pro jakýkoliv režim restartu; cíle database wallet potřebují agenta, wallet_path, provider Oracle a update_tns_names=false (rac_nodes je rovněž odmítnut); cíle web_server a load_balancer jsou odmítnuty. Existující cíle se nemění — zapnutý cíl, který tato pravidla porušuje, nyní svou rotaci ukončí chybou s ID cíle a důvodem místo přeskočení nebo hlášení falešného úspěchu a vždy ho lze vypnout nebo smazat; editor v UI při uložení vypne starší update_tns_names=true a u nepodporovaných providerů a typů cílů ukáže alternativu. Před zapnutím automatické rotace prověřte cíle nasazení produkčních certifikátů na web_server, load_balancer, ne-Oracle položky Database Wallet a wallet cíle bez agenta; (3) se zapnutou volbou agenta install_chain_to_trust_store nainstaluje podřízená CA, která dosud neměla řetězec, při nasazení do trust store hostitele i svůj root — stejné chování, jaké vždy měly PFX importy s vloženým rootem. Rollout agentů: oprava nasazení do keystore JKS / PKCS#12 / Windows My na straně backendu/gateway funguje s již nasazenými agenty. Cíl Agent File (PEM), kroky agent_command (WebLogic restart, Oracle orapki), sémantika „pouze veřejné“ u windows_root / windows_ca a nasazení do Oracle wallet vyžadují agenta 1.0.61; starší agenti na tyto požadavky odpoví explicitní chybou unsupported proxy message type a krok nasazení selže rychle. Nasazení Oracle a WebLogic jsou kryta kontraktními testy proti protokolu agenta — před spolehnutím v produkci je ověřte proti skutečnému hostiteli s orapki / WLST na stagingu. Nedosažitelná duplicitní cesta adopce z discovery (CertificateDiscoveryService, handlers_discovery.go) byla odstraněna; její filtry seznamu (managed_certificate_id, discovered_by_agent_id, expirace) byly sloučeny do živého endpointu GET /discovered-certificates jako query parametry agent_id, managed_certificate_id a expiring_within_days a POST /discovered-certificates/{id}/ignore nyní přijímá volitelné tělo {"reason": "..."}, které se ukládá jako state_reason a zaznamenává do auditního logu — jediné dvě schopnosti odstraněného kódu, které živá cesta postrádala; adopce, hromadná adopce i obohacení detailu tam už byly nadmnožinou. Oba živé endpointy získaly Swagger dokumentaci a pět nikdy nenaroutovaných cest /discovery/certificates* ze Swagger výstupu zmizelo. Nepřibývají žádné nové proměnné prostředí, Helm hodnoty ani změny formátu release balíčku.
Dopad na upgrade (custody klíčů certifikátů, validace CSR, normalizace serialů) — Žádná databázová migrace, žádná nová proměnná prostředí, žádná Helm hodnota, žádná změna formátu release balíčku a žádná změna kontraktu Terraform provideru (resource mazevault_certificate je založen na CSR a je neměnný; doplnění klíče je akce operátora). Změny API jsou volitelné a aditivní: expected_certificate_id na POST /certificates/import a POST /certificates/import/file, key_source_file v odpovědi preview-multi, identity_normalized v odpovědi POST /admin/certificates/backfill a hodnota failed v enumu status požadavku na certifikát. Změny chování, které je třeba před upgradem produkčního inventáře prověřit: (1) šablony s neprázdným allowed_key_sizes nyní odmítají nahraná CSR s jinou velikostí klíče už při odeslání — včetně ADCS a externích CA, které dříve nekontrolovaly nic — ověřte proto seznam u šablon používaných se zákaznickými CSR (prázdný seznam = libovolná velikost); (2) šablony s explicitní san_config ji nyní vynucují i na nahraná CSR — sloupce allow_additional_sans a max_san_count se pro nahraná CSR záměrně nepoužívají, protože je editor šablon nikdy spolehlivě neukládal; (3) při startu primary proběhne na pozadí idempotentní průchod, který přepíše serial_number / thumbprint_sha256 / thumbprint_sha1 pouze u řádků odlišných od uloženého DER (hex serialy zapsané ACME/Vault/finalizací externích objednávek, velká písmena v otiscích); certifikáty z interní CA, ADCS, DigiCert, Venafi a importované jsou již kanonické a nedotknou se jich, vazby na CA/CA účty ani nastavení obnovy se nikdy nemění a nevznikají žádné sync události; (4) import certifikátu, který už existuje v jiném projektu, nyní vrací chybu místo tichého připojení materiálu k záznamu cizího projektu; (5) automaticky schválené požadavky, jejichž vydání selže, jsou označeny failed (externě odložené čekající klíče jsou záměrně ponechány i s referencí pro úklid operátorem — při selhání CA se ze secret manageru nic nemaže) a ručně schválené se vrací do pending. Odložená rozhodnutí (zdokumentována v architektonické referenci): unikátní index na certificates.thumbprint_sha256 (čekající externí objednávky a legacy duplicity by rozbily upgrade), vynucení přiřazení šablony k projektu při odeslání CSR (vyžaduje MAJOR bump kvůli API/Terraform klientům), vlastní EKU OID v interní CA a limit pokusů / detekce zamítnutí u ADCS objednávek, které zůstávají trvale pending.
Dopad na upgrade (Rotační šablony) — Verze 1.0.61 přidává jednu idempotentní migraci, 000195_rotation_template_policy_fields, která přidává tři sloupce do rotation_config_templates: lead_time_days (INT, výchozí 0), grace_period_days (INT, výchozí 0) a secret_custody_mode (VARCHAR, výchozí local). Kontrola zdraví databáze nyní ověřuje nové sloupce politiky šablon. Terraform resource mazevault_rotation_template získává volitelné argumenty lead_time_days, grace_period_days a secret_custody_mode a Go SDK je odpovídajícím způsobem aktualizováno; všechny přírůstky jsou aditivní a zpětně kompatibilní, žádný resource, datový zdroj, API endpoint ani SDK kontrakt se neodebírá ani nepřejmenovává. Nepřidávají se žádné nové proměnné prostředí, hodnoty Helm ani změny formátu release balíčku. Provider a SDK navíc vystavují již perzistovaná pole project_id a retry_delay_seconds (bez migrace) a organization_id na resource je Optional+Computed. Upozornění: při vytvoření šablony se explicitní 0 u max_retry_attempts, retry_delay_seconds nebo timeout_minutes neuplatní — server použije své výchozí hodnoty (3/5/10); tato pole vynechejte nebo nastavte kladnou hodnotu (pozdější změna na 0 přes update se uplatní).
Dopad na upgrade (Životní cyklus agentů) — Tato funkce přidává jednu idempotentní migraci, 000196_agent_lifecycle_metadata, která do tabulky agents přidává nullable lifecycle sloupce (unregistered_at, unregistered_by, lifecycle_reason, lifecycle_reason_category, identity_revoked_at, uninstall_status, uninstall_requested_at, uninstall_completed_at, replaced_by_agent_id); kontrola zdraví databáze nové sloupce validuje. Druhá idempotentní migrace, 000198_deployment_purpose, přidává do tabulky deployments sloupec purpose (VARCHAR, výchozí standard), aby bylo možné odlišit autorizovaný jednorázový náhradní token od standardního enrollment tokenu — pouze náhradní token může znovu zaregistrovat vyřazeného agenta; kontrola zdraví databáze validuje i tento sloupec. Všechny změny jsou aditivní a zpětně kompatibilní. Guard RequireActiveAgent na JWT-autentizovaných agentních routách znamená, že agenti, kteří byli odregistrováni, revokováni nebo smazáni, jsou nyní odmítnuti i s neexpirovaným tokenem; podporovanou cestou obnovy zůstává re-enrollment přes platný deployment (nebo jednorázový náhradní) token — starší agenti zůstávají kompatibilní, protože se při odmítnutí jednoduše znovu zaregistrují. Přidány jsou čtyři aditivní agent:admin API endpointy (/agents/:id/lifecycle-impact, /unregister, /reregister, /uninstall) plus aditivní DELETE /api/v1/deployments/:id (deployment:write). Odpovědi list deploymentů nyní vynechávají bootstrap token (DeploymentResponse), zatímco odpověď create jej nadále vrací jednou (DeploymentCreatedResponse) — Go SDK i Terraform resource mazevault_deployment mají nezměněný kontrakt a token na create stále dostávají. Delete resource mazevault_deployment v Terraform provideru nyní volá nový delete endpoint (dříve no-op pouze ve stavu), takže terraform destroy zneplatní enrollment token na straně serveru; Read resource navíc znovu naplní organization_id, takže importovaný deployment lze zničit. Registrovaní agenti nejsou dotčeni. Vzdálená odinstalace je opt-in a pokouší se pouze o připojené Linux balíčkové instalace. Pro tuto funkci nejsou žádné nové proměnné prostředí, hodnoty Helm ani změny formátu release balíčku.
Dopad na upgrade (Bezpečnost a závislosti) — Jedná se pouze o změny závislostí a build-time: žádné databázové migrace, proměnné prostředí, hodnoty Helm ani změny formátu release balíčku a žádné změny kontraktů API, Go SDK ani Terraform provideru.
Dopad na upgrade (Frontend MUI v9 a Node toolchain) — Upgrade Material UI na v9 je interní frontendová změna bez dopadu na aplikační routy, chování, backend/API/Go SDK/Terraform kontrakty, proměnné prostředí, hodnoty Helm nebo formát release balíčku. Operátoři, kteří frontend sestavují ze zdrojů, nyní potřebují Node ≥ 22.22 (CI i kontejnerový image frontendu už běží na Node 24; .nvmrc fixuje Node 24 pro lokální vývoj). Runtime nasazení předsestaveného image frontendu není dotčeno.
Dopad na upgrade (Zálohy rotace) — Tato změna přidává jednu idempotentní migraci, 000197_rotation_backup_lifecycle, která do tabulky rotation_backups přidává sloupce status (VARCHAR, výchozí pending), acknowledged_at a acknowledged_by, dopočítá status z restored_at a nahrazuje starý index expirace za částečný index pro úklid plus index na status; kontrola zdraví databáze nové sloupce validuje. Přidává se jedna nová volitelná runtime proměnná prostředí — MAZEVAULT_ROTATION_BACKUP_RETENTION_DAYS (výchozí 7) — propagovaná do .env.example, docker-compose, instalátorů i všech hodnot Helm. Přidány jsou čtyři aditivní rotation API endpointy pod /rotation/backups (list rotation:read; restore rotation:execute; reveal/acknowledge rotation:write, přičemž reveal/restore navíc vynucují secret:read). Všechny změny jsou aditivní a zpětně kompatibilní — žádný resource, datový zdroj, API endpoint ani SDK kontrakt se neodebírá ani nepřejmenovává — a nemění se formát release balíčku. Protože insert zálohy nyní uspěje, aktivuje se poprvé mechanismus zálohy před rotací a automatického rollbacku; zálohy vyžadující ruční obnovu jsou zviditelné přes nové endpointy a metriku mazevault_rotation_backups_recovery_required.
Dopad na upgrade (Enterprise Functions / chránění Deploymentu) — Jde pouze o reorganizaci UI a vynucení licence: žádná databázová migrace, žádná proměnná prostředí, žádná hodnota Helm ani změna formátu release balíčku. Nový klíč license feature deployment_management je přidán do sad PoC a Enterprise odvozovaných funkcí getLicenseFeatures (state-aware: active / grace / expiring) a FeatureLicenseMiddleware je aplikován na CRUD skupinu /api/v1/deployments. Nemění se žádná API routa, schéma požadavku/odpovědi, Go SDK ani kontrakt Terraform provideru a plocha Swagger je beze změny. Změna chování: tenanti na plánu Small Business nebo bez licence, kteří dříve dosáhli na Deployment CRUD API, nyní dostanou HTTP 403 a upgrade banner; PoC a Enterprise tenanti nejsou dotčeni. Neautentizované UUID-chráněné bootstrap endpointy agenta zůstávají nechráněné, takže instalace agentů není ovlivněna. Text upgrade banneru pro SSH, Configuration a KeyTab byl sjednocen na „PoC or Enterprise“.
Dopad na upgrade (offload klíčů v Orchestrator módu) — Pouze backendová změna: žádná databázová migrace, žádná nová proměnná prostředí, žádná změna API kontraktu. Dvě chování jsou záměrně přísnější a operátoři provozující Orchestrator mód by je měli zkontrolovat: (1) Výběr integrace se už nerozšiřuje mimo scope volajícího. Offload tokenu, keytabu nebo privátního klíče, který nese scope projektu/organizace a v něm nenajde povolenou integraci typu secret_manager / key_storage / hsm, nyní selže s no enabled key storage integration found for project/organization … místo tichého použití první integrace kdekoli v systému; explicitně zvolené integration_id, které neexistuje nebo je vypnuté, je odmítnuto stejně. Ujistěte se, že každá organizace používající spravované tokeny nebo keytaby v Orchestrator módu má povolenou secret-manager integraci v některém ze svých projektů. (2) Limit velikosti Azure Key Vault se vynucuje před zápisem. Hodnoty, jejichž base64 přenosové kódování přesáhne 25 600 bajtů (≈19 200 raw bajtů), jsou odmítnuty s 400 a přesným limitem; jde o dokumentovaný strop Azure na jeden secret, ne o omezení MazeVaultu — větší hodnoty vyžadují jako cíl úložiště klíčů projektu integraci HashiCorp Vault nebo AWS Secrets Manager (64 KB). Secrety vytvořené v Key Vaultu touto verzí používají nové ploché pojmenování (mazevault-token-…, mazevault-keytab-…, mazevault-<cn>-<serial>); existující reference uložené u certifikátů se respektují beze změny (update_version vytvoří novou verzi téhož secretu). V Key Vaultu se nic nepřejmenovává ani nemigruje.

Verze 1.0.60¶

Datum vydání: 2026-07-20

Nové funkce¶

Správa tokenů — externí API tokeny s povinným sledováním expirace a nasazením přes agenta — Nová Enterprise funkce (licence PoC nebo Enterprise, feature token_management) pro správu externě vydaných API tokenů — například tokenů Jira nebo Signi — které lze obnovit pouze ručně v GUI zdrojového systému. Každý token se ukládá s povinným datem expirace a volitelným per-token předstihem upozornění (výchozí 30 dní); MazeVault před vypršením vyvolá incident token_expiry přes stávající notifikační kanály (e-mail, webhook, Teams, Slack, Jira, SMSEagle) a po vypršení jej eskaluje na critical. Hodnoty tokenů jsou ve standardním režimu šifrované at-rest (AES-256-GCM), nebo se v režimu Orchestrator offloadují do nakonfigurovaného externího správce tajemství (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault). Token lze volitelně navázat na projekt a nasadit na stejné typy cílů jako tajemství, přičemž se znovupoužívají sdílené doručovací exekutory MazeVault: konfigurační soubor na serveru spravovaný agentem (JSON/YAML/ENV klíč→hodnota, s volitelným povoleným post-install příkazem), Kubernetes secret, secret v Azure Key Vault nebo secret v AWS Secrets Manager (zápis do Windows registrů / IIS je záměrně odložen). Ruční akce obnovit zaznamená nově získanou hodnotu a nové datum expirace, uzavře otevřený incident expirace a znovu nasadí cíle označené pro sync-při-obnově. Správa tokenů je záměrně oddělená od projektové Správy klíčů (projektová tajemství) i od System Keys v nastavení organizace (infrastrukturní klíče MazeVault) a nachází se pod novou navigační skupinou Enterprise Functions. Přístup řídí nová oprávnění token:read / token:write / token:delete / token:admin — nasazení a obnova vyžadují token:write (admin je implikuje), zobrazení uložené hodnoty tokenu vyžaduje token:admin. Funkce je plně spravovatelná přes nový Terraform resource mazevault_token a datový zdroj mazevault_tokens.
Dopad na upgrade (Správa tokenů) — Přidává dvě idempotentní migrace: 000193_token_management (vytvoří tabulky managed_tokens a token_deployment_targets, naseeduje oprávnění token:* do stávajících rolí — org_admin plně; operator read/write/delete; user a auditor pouze read) a 000194_token_target_types (zobecní token_deployment_targets o target_type / integration_id / config, takže doručení tokenu znovupoužívá sdílené exekutory secret/certifikátů). Nepřidávají se žádné nové proměnné prostředí, hodnoty Helm ani změny formátu release balíčku — funkce znovupoužívá stávající infrastrukturu šifrování, offloadu tajemství, notifikací/incidentů, doručovacích rotačních kroků a licencování. Kontrola zdraví databáze nyní ověřuje obě nové tabulky. Terraform provider získává aditivní resource mazevault_token a datový zdroj mazevault_tokens; žádný stávající resource, datový zdroj, API endpoint ani kontrakt Go SDK se nemění ani neodebírá. Endpointy jsou chráněné feature token_management (PoC a Enterprise); bez ní API /api/v1/tokens vrací HTTP 403 a UI zobrazí upgrade banner.

Vylepšení¶

Admin dávkové řešení na dedikovaných stránkách problémů rotace a synchronizace — Systémový administrátor nyní může vybrat jednotlivé řádky nebo všechny aktuálně viditelné řádky na stránce Rotation Problems a v každé sekci stránky Synchronization Problems. Frontend záměrně opakuje existující auditované single-item akce s nejvýše třemi souběžnými požadavky, zobrazuje průběh i částečná selhání a po dokončení znovu načte dotčené seznamy; nevzniká žádná neauditovaná bulk mutační cesta. Selhání rotace se acknowledgeují a dostupný navázaný otevřený incident se uzavře. Sync failures a blocked-seed incidenty se acknowledgeují ve vlastních sekcích, zatímco pending sync konflikty lze dávkově pouze ignorovat, což změní lokální stav konfliktu bez zápisu kterékoli hodnoty do externího provideru. „Vše viditelné“ je záměrně omezené aktuální stránkou a každé potvrzení uvádí přesný počet dotčených položek. Jednotlivé remediation akce zůstávají dostupné neadmin operátorům se stávajícími write oprávněními; dávkové ovládání vidí pouze systémový administrátor.
HSM/KMS backend HashiCorp Vault Transit — mazevault_hsm_device nyní podporuje provider_type = hashicorp_vault postavený na engine HashiCorp Vault Transit. Dříve validace hodnotu přijala, ale instanciace selhávala s unsupported HSM provider: hashicorp_vault, protože implementace neexistovala. Klíče Vault Transit generuje a drží Vault (RSA-2048/3072/4096, ECDSA P-256/P-384/P-521); podpis probíhá vzdáleně přes endpoint Transit sign, takže privátní klíčový materiál nikdy neopustí Vault. Implementován je test připojení zařízení, výpis klíčů, získání veřejného klíče, vzdálený podpis (používaný podpisem interní CA a dalšími operacemi směrovanými přes HSM) i mazání klíčů. Konfigurace přijímá vault_url, token a volitelný mount_path (výchozí transit). Wrapping klíč-šifrujícího-klíče (KEK) i nadále obsluhuje samostatné systémové HSM rozhraní a je mimo rozsah tohoto provideru.
Certifikátové šablony přizpůsobené providerovi pro externí komerční CA — Formulář certifikátové šablony se nyní přizpůsobuje schopnostem providera vybraného vydávajícího CA účtu, místo jednoho pevného sadu polí pro každou autoritu. Každá externí CA má jiné API a model vydávání, takže formulář řídí schopnosti deklarované providerem (vystavené na GET /ca-providers/{type}/schema): provideri s produktovým katalogem (SSLMarket, DigiCert) nabízejí certifikátový produkt jako dropdown ze synchronizovaného katalogu CA — typ certifikátu se odvodí z vybraného produktu a volné pole external template OID se skryje; provideri vyžadující doménovou validaci nabízejí na šabloně metodu doménové validace (email / dns / file), uloženou jako dcv_method (migrace 000191); ACME issuery dál zobrazují ACME challenge policy; interní CA ani jedno. SSLMarket provider nyní odvozuje product_code z navázaného CA produktu šablony (s fallbackem na volný kód a poté výchozí hodnotu účtu) a respektuje per-template metodu validace; DigiCert rovněž preferuje per-template metodu. Nový volitelný argument dcv_method je dostupný na Terraform resource mazevault_certificate_template. Stávající šablony nejsou dotčené: nový sloupec je nullable a prázdná hodnota znamená „použij výchozí providera/účtu".

Opravy chyb¶

Terraformem spravované tokeny mají platný a state-safe životní cyklus — Resource mazevault_token používal rezervované root jméno atributu provider, kvůli čemuž Terraform validace schématu resource odmítla. Štítek je nyní dostupný jako token_provider a verzovaný state upgrader zachová hodnoty existujícího stavu. Čtení a mazání tokenů nyní považuje HTTP 404 za nepřítomný resource, ale zachová stav při chybě autorizace, transportu nebo serveru. Prázdná odpověď description / project_id už nenechá ve stavu starou neprázdnou hodnotu. Nové tokeny mohou použít Terraform 1.11+ value_wo s value_wo_version, takže plaintext není v plánu ani stavu; legacy value zůstává podporované, ale je výslovně dokumentované jako stateful. Import nyní podporuje správu pouze metadat. Migrace existujícího resource z value na value_wo není automatická, protože replacement změní ID tokenu a kaskádově smaže jeho deployment cíle.
Rotation Failure Triage zobrazuje skutečný počet otevřených problémů a průběžnou frontu deseti položek — Widget Overview dříve zobrazoval počet incidentů ve výchozí dvacetipoložkové stránce API jako celkovou hodnotu, takže tenant s více než 20 otevřenými selháními rotace vždy viděl nesprávný počet. Widget nyní používá autoritativní total z existující paginované odpovědi incidentů, pro zobrazení načítá pouze deset nejnovějších nevyřešených rotation-failure incidentů a po každém jednotlivém uzavření znovu načte první stránku, takže se fronta okamžitě doplní dalším nevyřešeným incidentem. Zavádějící page-local badge High/Critical byl odstraněn. Overview záměrně zůstává povrchem pro jednotlivé řešení bez výběru nebo dávkového uzavření.
Metrika „Missing in PROD“ na Secrets Dashboardu nyní správně odráží cross-environment paritu — KPI dlaždice na Secrets Dashboardu dříve označená Missing in PROD ve skutečnosti nikdy nekontrolovala produkční prostředí ani organizační nastavení is_production. Počítá secret klíče, které existují alespoň v jednom aktivním (porovnávaném) prostředí, ale chybí v jiném aktivním prostředí — jde o signál cross-environment parity, který vyžaduje aspoň dvě aktivní prostředí. Na instancích bez produkčního prostředí (například testovací tenant pouze s development, integration, migration a testing) to vedlo k matoucí nenulové hodnotě „Missing in PROD“. Dlaždice je nyní označená Missing (Cross-Env) jak v přehledu Secrets Dashboardu, tak v pohledu Reports, čímž odpovídá tabulce Missing Secrets (Cross-Environment) pod ní. Podkladový cross-environment výpočet zůstává beze změny — opraveno bylo pouze zavádějící pojmenování a popisek.
Události custody klíčů v Orchestrator Mode se spolehlivě ukládají — V Orchestrator Mode se při offloadu privátního klíče (například certifikátového klíče odeslaného do Azure Key Vaultu) zaznamenávala custody audit událost, jejíž hodnota metadata byla prázdný řetězec. Protože key_custody_events.metadata je sloupec typu PostgreSQL JSONB, insert selhal s invalid input syntax for type json (SQLSTATE 22P02) a custody záznam se ztratil — pouze se zalogovalo varování — přestože samotný offload klíče proběhl úspěšně. Custody události nyní vždy ukládají syntakticky validní JSON: nenastavená nebo prázdná hodnota metadata se na hranici zápisu normalizuje na prázdný JSON objekt ({}), takže každý offload, načtení i smazání klíče vytvoří trvalý custody audit záznam. Volající, kteří už předávají strukturovaná metadata, nejsou dotčeni. Health check databáze nově validuje i sloupce key_custody_events.
Vydávání certifikátů přes SSLMarket opraveno na reálné SSLmarket API — Vydání certifikátu přes SSLMarket CA účet selhávalo s API request failed with status 400: {"error":["No route found"]} na standardních i Orchestrator Mode instancích. SSLMarket provider byl implementovaný proti REST tvaru, který neodpovídá zveřejněnému SSLmarket API. Provider nyní cílí na skutečné endpointy a payloady: objednávky se odesílají na POST /order/certificate/{product_code} s plochým tělem objednávky (doména, SANs, roky, CSR, povinné dv_auth_method a pole owner/authorized-contact/technical-contact/invoice, která se při nekonfigurování doplní z defaultů SSLmarket účtu); detail objednávky, stažení certifikátu (podle order id a formátu), tokeny doménové validace (DCV) a revokace nyní používají správné cesty; resolvování produktu čte reálný katalog {"products":[…]}; a odpovědi se parsují podle skutečných JSON tvarů API (stringové identifikátory, pole dns_names a stavy objednávky paid/requested). Autentizace (X-Auth-Token) a base URL byly už dříve správné a zůstávají beze změny. Vydávání certifikátů i asynchronní poller objednávek externí CA nyní proti SSLMarketu doběhnou.
Audit události push secretů (Orchestrator a Sync) už neselhávají na porušení cizího klíče — V Orchestrator Mode se při pushi secretu do externího provideru (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault) zaznamenávala audit událost SECRET_PUSH_CREATE / SECRET_PUSH_UPDATE, jejíž user_id bylo omylem nastaveno na ID projektu místo uživatele. Protože audit_events.user_id má cizí klíč na users(id), insert selhal s violates foreign key constraint "audit_events_user_id_fkey" (SQLSTATE 23503) a audit záznam se ztratil, přestože samotný externí push proběhl úspěšně — externí secret se tak rozešel s auditní stopou. Audit události push secretů i sync-seedu se nyní přiřazují iniciujícímu uživateli (a u systémem iniciovaných synchronizací vyřešenému systémovému aktérovi), takže se ukládají správně. Jako obrana do hloubky nově zapisovač auditu garantuje i trvanlivost: pokud by se jakákoli audit událost nepodařila uložit kvůli chybné referenci aktéra, je jednou zopakována s prázdným (nepřiřaditelným) aktérem místo zahození; a jen pokud je databáze zcela nedostupná, je celá událost vyemitována do centrálního strukturovaného logu jako poslední záchrana. Původní lokální soubor emergency logu (/var/log/mazevault/emergency_audit.log), nepoužitelný na read-only souborových systémech kontejnerů v Kubernetes, byl odstraněn. Nová metrika mazevault_audit_persist_failures_total umožňuje alertování jakékoli takové poslední záchrany.
Merkle integritní cache nyní sleduje změny secretů — Inkrementální Merkle integritní cache znala pouze slovník událostí certifikátů/keytabů (create / update / delete) a tiše ignorovala události secret služby v minulém čase (created / updated / deleted), logovala merkle cache updater: unknown event type a nechávala integritní cache secretů po každé změně zastaralou. Aktualizátor cache nyní přijímá obě formy, takže operace create/update/delete nad secrety správně aktualizují Merkle integritní strom.
Zálohy rotace jsou nyní šifrované a podporují automatický rollback — Rotační orchestrátor byl spouštěn bez zapojeného encryptoru, takže pre-rotační zálohy degradovaly na neobnovitelné odkazy na verzi a logovaly rotation backup requested but encryptor not configured — rollback will be limited. Automatický rollback selhané rotace tak nebyl k dispozici. Orchestrátor nyní při startu dostává systémový encryptor, takže se pre-rotační stav ukládá jako šifrovaná záloha a automatický rollback je obnoven. Zálohy externích names_only secretů se i nadále spoléhají na vlastní historii verzí externího provideru, stejně jako dříve.
Entra ID integrace přijímají workload-identity (AKS) pro background autentizaci — Konfigurace Entra ID integrace (používané pro rotaci secretů app registrací a synchronizaci Microsoft Graphu) s background_auth_method=workload_identity byla odmítnuta s unsupported background_auth_method, přestože Microsoft Graph klient i sdílená Azure credential factory federovanou workload identity na AKS už podporují. Tři samostatné validační brány — vytvoření/úprava integrace, test připojení a runtime kontrola konzistence používaná při rotaci — hodnotu ve výchozím stavu odmítaly, takže integraci nešlo vytvořit, nebo při vynucení selhala později při rotaci s configuration is inconsistent. Všechny tři brány nyní workload_identity přijímají; ta — stejně jako managed_identity — nevyžaduje v konfiguraci integrace žádné statické přihlašovací údaje: na workload-identity clusteru runtime provede federovanou výměnu tokenu pro nakonfigurované (nebo webhookem injektované) client ID managed identity. To odemyká rotaci Entra credentials na AKS workload-identity clusterech bez dedikované client-secret app registrace.
Krok rotace Spring Actuator Refresh už nepadá na chybné konfiguraci — Post-rotační krok spring_actuator používal nekontrolované typové asertace na actuator_url a na položkách volitelného seznamu endpoints, takže špatný konfigurační klíč (například url místo actuator_url) nebo ne-stringová položka způsobily pád workeru místo srozumitelné chyby. Krok nyní vstup validuje defenzivně a vrací strukturovanou chybu, a refresh URL sestavuje bezpečně tak, aby základní URL, koncové lomítko nebo URL, které už končí na /actuator nebo /actuator/refresh, nikdy nevytvořilo zdvojenou cestu.
Post-rotační doručení secretu do Key Vaultu a dalších cílů nyní dostane vyrotovanou hodnotu — Post-rotační doručovací akce (push do Azure Key Vaultu, AWS/GCP/OCI secret manager, DevOps proměnné) vyžadují čerstvě vyrotovanou hodnotu secretu, ale fáze post-rotačních akcí sestavovala kontext, který ji vynechával, takže doručovací akce logovala new_password not found in input context a zápis tiše přeskočila. Vyrotovaná hodnota se záměrně nikdy neukládá, proto se nyní řeší až v době provedení z právě aktualizovaného MazeVault secretu — shodně, ať akce běží na primary nebo je delegována na gateway (hodnotu si načte provádějící runtime a nikdy se nepřenáší v payloadu gateway úlohy). Doručení u rotací Entra credentials i nadále probíhá přes dedikované seedované doručovací workflow. Jako zpevnění se předchozí hodnota z Key Vaultu zachycená pro rollback nyní z uloženého záznamu post-akce redaguje, takže se do historie rotace nezapisuje žádný citlivý materiál.
Azure Managed HSM / Key Vault HSM zařízení lze nyní otestovat a používat — Instanciace zařízení azure_managed_hsm (pro test připojení i pro jakékoli podepisování CA, offload klíčů, rotaci klíčů či šifrování secretů skrz něj směrované) selhávala s CredentialFactory is required for AzureKVProvider, protože HSM device služba vytvářela Azure provider bez credential factory. Azure credential factory je nyní do HSM device služby injektována a protažena do factory provideru, takže Azure Managed HSM zařízení se inicializují se skutečným Azure credentialem.
Ruční synchronizace secret-manager integrace už neodmítá nekanonické hodnoty typu — Spuštění ruční synchronizace na secret-manager integraci mohlo selhat s sync not supported for integration type: secret-manager, pokud uložený typ integrace používal pomlčku místo kanonické formy s podtržítkem. Typy integrací se nyní při vytvoření kanonizují (malá písmena, ořez, pomlčky na podtržítka) a guard ruční synchronizace porovnává proti kanonické formě, takže secret-manager a secret_manager jsou brány shodně. Migrace 000192 normalizuje případné stávající nekanonické hodnoty project_integrations.type, aby exact-match kontroly (ruční sync, sync rules, key offload) zůstaly konzistentní.
Pull/obousměrná sync pravidla vyžadují cílové prostředí předem — Vytvoření pull nebo obousměrného sync pravidla bez target_environment bylo přijato, ale později při provedení selhalo hluboko v kanonizéru prostředí s environment slug is empty. Vytvoření sync pravidla nyní vyžaduje a kanonizuje target_environment pro každé pravidlo, které není čistý push (push pravidla odvozují prostředí ze zdrojového secretu), a vrací srozumitelnou validační chybu místo matoucího runtime selhání.
Vydávání ACME certifikátů nyní dokončí finalizaci (Let's Encrypt / ACME CA) — Report z v1.0.59 popisoval, že vydávání přes ACME projde validací dns-01, ale selže při finalize s chybou POST-as-GET requests must have an empty payload / must have a nil body; to bylo end-to-end reprodukováno proti lokálnímu Pebble serveru. Nalezeny a opraveny dva defekty. Zaprvé MazeVault odesílal CSR na URL objednávky (order.URI) místo na dedikovanou finalize URL objednávky (order.FinalizeURL); protože URL objednávky je read-only POST-as-GET zdroj, odeslání těla CSR tam CA odmítla. Zadruhé poté, co CSR dorazil na správný finalize endpoint, některé RFC 8555-kompatibilní servery (včetně Pebble) nevrací na finalize odpovědi hlavičku Location, takže interní post-finalize poll v ACME klientovi mířil na prázdnou URL a selhal, přestože CSR byl přijat; vydávání se nyní zotaví dotázáním známé URL objednávky a stažením vydaného certifikátu. End-to-end vydávání dns-01 přes finalize je ověřeno reprodukčním testem proti Pebble (build tag acme_pebble).
Dopad upgradu — Verze 1.0.60 je oprava pojmenování a popisku bez databázových migrací, environment proměnných, Helm values nebo změny formátu release balíčku. V endpointu přehledu secretů dashboardu (GET /api/v1/dashboard/secrets/overview) se pole odpovědi missing_in_prod přejmenovává na missing_cross_env. Jde o interní pole dashboardu, které konzumuje pouze frontend MazeVaultu; není součástí Go SDK ani Terraform provideru, takže žádný integrační kontrakt není dotčen. Logika cross-environment parity a výpis chybějících secretů zůstávají funkčně beze změny.
Dopad upgradu (Orchestrator custody a SSLMarket) — Oprava ukládání custody klíčů v Orchestrator Mode a oprava SSLMarket provideru jsou pouze backendové změny bez databázových migrací, environment proměnných, Helm values nebo změny formátu release balíčku. Pro vydávání přes SSLMarket musí integrace CA účtu nastavit správný product_code (SSLmarket účet může nabízet produkty — například trial certifikáty — které nevrací API katalog produktů, a proto se musí nakonfigurovat explicitně) a, pokud účet nemá výchozí firemní data, nastavení owner/contact/invoice vyžadovaná zvoleným produktem. dv_auth_method má při nekonfigurování výchozí hodnotu Email.
Dopad upgradu (šablony přizpůsobené providerovi) — Funkce certifikátových šablon přizpůsobených providerovi přidává jeden nullable sloupec přes migraci 000191 (certificate_templates.dcv_method) a jedno runtime-počítané pole (template_form) v odpovědi GET /ca-providers/{type}/schema; obojí je aditivní a zpětně kompatibilní. Žádné environment proměnné, Helm values ani změny formátu release balíčku. Terraform resource mazevault_certificate_template získává volitelný argument dcv_method; stávající konfigurace fungují beze změny.
Dopad upgradu (Audit, Merkle a rotace) — Oprava přiřazení aktéra u auditu push secretů, zpevnění trvanlivosti auditu, oprava Merkle integritní cache a oprava šifrování záloh rotace jsou pouze backendové změny spolehlivosti bez databázových migrací, environment proměnných, Helm values nebo změny formátu release balíčku. Přidává se jedna aditivní Prometheus metrika mazevault_audit_persist_failures_total; žádná stávající metrika, API endpoint, Go SDK ani kontrakt Terraform provideru se nemění. Lokální fallback /var/log/mazevault/emergency_audit.log byl odstraněn ve prospěch centrálního strukturovaného logu, takže poslední záchranný audit sink nyní funguje i na read-only souborových systémech kontejnerů.
Dopad upgradu (Entra WI, doručení rotace, HSM a validace sync) — Tyto opravy přidávají jednu idempotentní datovou migraci 000192_canonicalize_integration_type, která normalizuje stávající hodnoty project_integrations.type na kanonickou formu s malými písmeny a podtržítky; je pouze datová a zpětně kompatibilní. Žádné nové environment proměnné, Helm values ani změny formátu release balíčku. background_auth_method=workload_identity je nyní přijímaná hodnota pro Entra integrace (včetně API povrchu mazevault_integration) a pull/obousměrná sync pravidla nyní vyžadují target_environment při vytvoření. Žádný stávající API endpoint, Go SDK ani kontrakt Terraform provideru se neodstraňuje ani nepřejmenovává.
Dopad upgradu (Vault HSM a ACME finalize) — HashiCorp Vault Transit HSM provider a oprava ACME finalize jsou pouze backendové bez databázových migrací, environment proměnných, Helm values nebo změny formátu release balíčku. Provider hashicorp_vault pro HSM zařízení je aditivní; žádná stávající konfigurace HSM zařízení se nemění. Oprava ACME finalize opravuje pouze tok vydávání certifikátů; žádný API endpoint, Go SDK ani schéma Terraform provideru se nepřidává, neodstraňuje ani nepřejmenovává. Reprodukční test proti Pebble je za build tagem acme_pebble a v běžném CI neběží.
Dopad upgradu (UX řešení problémů) — Pravdivý počet v Rotation Failure Triage a administrátorské dávkové workflow jsou pouze frontendové změny. Znovupoužívají existující metadata paginace incidentů a stávající single-item mutační endpointy, oprávnění i auditní události. Nejsou potřeba žádné databázové migrace, změny API nebo Swagger kontraktu, nová RBAC oprávnění, environment proměnné, Helm values, změny release balíčku, Go SDK ani Terraform provideru.

Bezpečnost a aktualizace závislostí¶

Odstraněny Trivy CRITICAL/HIGH zranitelnosti závislostí napříč všemi moduly — Trivy filesystem sken v dev pipeline (CRITICAL,HIGH, --ignore-unfixed) selhával na opravených, ale zastaralých závislostech. Všechny dotčené balíčky byly povýšeny na opravené verze a ověřeny přes go build, go vet, unit testy modulů a govulncheck (0 dosažitelných zranitelností), plus build frontendu a kompletní Vitest sada:
- Go — golang.org/x/text 0.37.0 → 0.39.0 (CVE-2026-56852 / GO-2026-5970, nekonečná smyčka v norm.Iter) v backend, cli, k8s-operator a terraform-provider-mazevault.
- Go — google.golang.org/grpc 1.79.3 / 1.80.0 → 1.82.1 (GHSA-hrxh-6v49-42gf / GO-2026-6061, xDS RBAC a HTTP/2 transport) v backend a terraform-provider-mazevault.
- Go — software.sslmate.com/src/go-pkcs12 0.7.0 → 0.7.2 (GO-2026-5052) v backend a agent; tuto dosažitelnou zranitelnost odhalil govulncheck, přestože ji Trivy kvůli severity filtru nehlásil.
- Frontend — axios 1.16.0 → 1.19.0 (GHSA-gcfj-64vw-6mp9 a související advisories).
React Router povýšen na v8 (major) — Frontend byl migrován z react-router-dom 7.17.0 na react-router 8.3.0, což řeší CVE-2026-55685 a GHSA-qwww-vcr4-c8h2. React Router v8 ruší samostatný balíček react-router-dom; všechny importy byly přesunuty na react-router (aplikace je deklarativní SPA používající BrowserRouter, takže vstupní bod react-router/dom není potřeba). react a react-dom byly zvednuty na minimum 19.2.7.
Dopad upgradu (Bezpečnost a závislosti) — Jde pouze o změny závislostí a build-time: žádné databázové migrace, environment proměnné, Helm values ani změny formátu release balíčku a žádné změny kontraktu API, Go SDK nebo Terraform provideru. Build frontendu nyní vyžaduje Node ≥ 22.22 (deklarováno novým polem engines v frontend/package.json); CI joby frontendu i Docker image frontendu už běží na Node 24. Povýšení React Router na v8 je interní frontend migrace bez změny aplikačních rout nebo chování; kompletní sada frontend unit testů prochází beze změny.

Verze 1.0.59¶

Datum vydání: 2026-07-18

Vylepšení¶

Pohledy rotace secretů se po dokončení na pozadí tiše aktualizují — Záložka Secrets nyní používá existující per-secret poller stavu rotace jako detektor události. Když rotace secretu na pozadí doběhne do koncového stavu, MazeVault načte pouze dotčený secret přes GET /api/v1/secrets/{id} a aktualizuje viditelné číslo verze bez reloadu celé tabulky secretů. Pokud je pro daný secret otevřený modal Version History nebo Rotation Configuration, modal si na místě znovu načte seznam verzí nebo historii exekucí. Nepřibývá žádný globální polling, toast, zvýraznění ani refresh celé stránky.
Samostatné řízení přístupu pro řešení synchronizačních problémů — Synchronizační problémy nyní používají oddělenou permission hranici sync:read / sync:write místo implicitního navázání akčních tlačítek na project:write. Role project_admin, certificate_manager a secret_manager mohou synchronizační problémy aktivně řešit, zatímco auditor a běžní uživatelé zůstávají v read-only režimu. Navigace i stránka Synchronization Problems tak odpovídají skutečnému oprávnění uživatele.
Akce pro sync failures a blocked seed incidenty jsou dostupné přímo z problémového pohledu — Globální stránka Synchronization Problems i projektová záložka sync konfliktů nově nabízí potvrzované akce pro retry, ignorování konfliktu, acknowledgement aktuálního sync failure fingerprintu a acknowledgement incidentu typu sync_seed_blocked. Badge v levé navigaci počítá souhrnný sync_problem_count, tedy konflikty, aktuální sync failures i blocked seed incidenty.
Dismissals synchronizačních problémů škálují jedním dávkovým dotazem — Výpis sync failures nyní vyhodnocuje acknowledged fingerprinty aktuálních selhání jedním dávkovým dotazem místo samostatného lookupu pro každé selhané sync pravidlo. Zachovává se dosavadní fingerprint semantika podle pravidla, času a chyby i chování soft-delete, ale pohled Synchronization Problems zůstává svižný i při větším počtu selhaných pravidel.
Export certifikátů spolehlivěji obsahuje issuer CA chain — Export certifikátu nyní normalizuje uložené certificate bundle a podle potřeby dohledá hierarchii vydávající interní CA přes parent CA záznamy. PEM/CRT a PKCS#7 exporty obsahují leaf certifikát následovaný issuer chainem, zatímco DER zůstává jako dříve leaf-only.
Readiness obnovy certifikátů rozumí interním CA účtům — Eligibility obnovy, rotation preflight i metadata rotačních resources nyní resolveují interní organizační CA účty přes jejich podkladovou CertificateAuthority. Obnovy podepisované interní CA reportují CA účet i skutečnou signing CA, stejně jako runtime renewal cesta.
Domain validation pro externí CA je viditelná a durable — Objednávky externích CA DigiCert a SSLMarket nyní zpřístupňují DCV instrukce přes zaregistrované endpointy renewal queue DCV a projektovou tabulku certifikátů. Certifikáty s čekajícím ověřením domény zobrazují akci View Domain Validation, která otevře existující DCV status panel, kde operátor vidí DNS/HTTP/email instrukce a může spustit provider re-check přímo z certificate workflow.
Nové certificate requesty přes externí CA mohou čekat na validaci providera — Vydání přes externí CA už nepředpokládá, že SignCSR okamžitě vrátí PEM certifikát. Pokud provider vrátí jen order ID, MazeVault uloží pending certificate placeholder, propojí ho s requestem, založí durable submitted_to_ca queue item a nechá external CA order poller request dokončit, jakmile provider certifikát zpřístupní.
CA account provider settings se persistují a dají spravovat Terraformem — Create/update/sync toky CA účtů nyní zachovávají ne-tajné provider settings jako DigiCert organization_id, server_platform_id, dcv_method, certificate_dcv_scope, vlastní base_url a SSLMarket defaulty v metadatech účtu. Terraform resource mazevault_ca_account přidává mapu settings pro tyto ne-tajné hodnoty a API klíče nebo ACME EAB materiál dál drží ve write-only credentials.
Terraform secrety podporují write-only hodnoty pro ephemeral hesla — Resource mazevault_secret nyní podporuje value_wo a value_wo_version pro write-only vstupy v Terraform 1.11+. Operátoři mohou vytvořit heslo pomocí ephemeral Terraform resource, například ephemeral "random_password", a předat ho do MazeVaultu bez uložení plaintextu do Terraform plánu nebo stavu. value_wo_version je uložený trigger pro opětovné odeslání: navyšte ho, když má Terraform poslat novou write-only hodnotu. Starší argument value zůstává podporovaný pro existující konfigurace a server-side generate zůstává dostupný pro secrety generované MazeVaultem.
API pro update secretu a Go SDK podporují metadata-only update — PUT /api/v1/secrets/{id} nyní bere value jako volitelné pole: vynechání aktualizuje pouze metadata a TTL, zatímco dodaná neprázdná hodnota dál vytváří novou verzi secretu. Go SDK zachovává stávající metodu UpdateSecret(id, value, ...) a přidává request-based update cestu, která umí value záměrně vynechat. Terraform provider ji používá pro životní cyklus write-only secretů.

Opravy chyb¶

Synchronization Problems už nezůstávají bez akčních ikon pro oprávněné role — Uživatelé, kteří mohli problémy vidět přes sync:read, dříve často neměli žádnou možnost je vyřešit, protože mutace byly svázané s project:write. Nové endpointy pro acknowledge sync failure a blocked seed incidentu jsou chráněné sync:write, auditované a záměrně omezené jen na synchronizační problémový povrch.
Ignorování sync konfliktu už nevyžaduje zápis do externího provideru — Resolution ignore nyní pouze uzavře lokální sync_conflicts řádek stavem ignored a nezapisuje do cílového secret manageru. To umožňuje trvale odložit známý konflikt bez rizika nechtěné změny externí hodnoty.
Acknowledgement sync failure je stabilní jen pro aktuální selhání — Sync failures odvozené ze sync_rules.last_sync_status se ukládají jako dismissal podle fingerprintu složeného z pravidla, času posledního syncu a chyby. Pokud další běh selže jinak, problém se znovu zobrazí; acknowledgment tedy nezakrývá nové nebo změněné selhání.
Editace konfigurace rotace už neukazuje falešné varování o částečném načtení — Modal konfigurace rotace secretu nyní adresuje historii rotací a readiness přes kanonické ID rotačního resource (rotation_configs.id / resource.resource_id) místo ID secretu. Tím se opravuje zavádějící hláška „Some rotation sections could not be loaded. Available data is shown." při otevření Secrets → Rotations → Edit pro nakonfigurovaný secret.
Rollback verze secretu spolehlivě funguje nad existující historií verzí — Rollback secretu nyní ukládá archivované řádky historie s vygenerovaným primárním klíčem, zachovává původní čas verze místo času archivace a metadata rollbacku aktualizuje přes modelovou serializační cestu. Frontend navíc zobrazuje backend message / error detail jako error notifikaci místo obecné odpovědi „Rollback Failed".
Legacy řádky historie secretů s chybějícím UUID jsou opraveny — Migrace 000189_fix_secret_version_null_uuid doplňuje validní UUID do legacy řádků secret_versions, které měly chybějící nebo nulové ID, a model SecretVersion nyní před vložením vygeneruje ID, pokud chybí. Tím se předchází kolizím primárního klíče a selháním rollbacku v prostředích, která už dotčené historické řádky obsahují.
Manuální rotace secretu už ve stagingu nevytváří duplicitní lokální verze — Krok pre_rotation_sync nyní před lokálním zápisem porovnává externí hodnotu s aktuální hodnotou secretu. Pokud jsou hodnoty shodné, krok hodnotu uloží jen jako kontext pro další kroky rotace a nezvýší verzi secretu. Tím se odstraňuje staging symptom, kdy jedna manuální rotace vytvořila dvě nové verze a matoucí mezilehlou systémovou verzi.
Historie verzí nyní zobrazuje správného autora u aktuální verze — Řádek aktuální (aktivní) verze v modalu Version History zobrazoval původního autora secretu místo aktéra, který secret naposledy změnil. Servisní vrstva nyní odvozuje autora aktuální verze z nejnovějšího archivovaného záznamu historie, který nese aktéra poslední změny — stejně jako všechny ostatní historické řádky. Automatické rotace spuštěné schedulerem se nadále zobrazují jako System; manuální triggery ukazují uživatele, který rotaci inicioval.
Pole certificate chain už neduplikují leaf certifikát — Issuance, import, renewal, ACME completion i dokončení objednávek u externích CA nyní normalizují certificate PEM data na hranici zápisu. CertificatePEM zůstává aktuální certifikát, ChainPEM ukládá pouze issuer certifikáty a PublicChainPEM ukládá celý bundle leaf-plus-chain. Existující kontaminovaná chain data se při exportu defenzivně normalizují.
ACME issuance ukládá leaf a chain odděleně — ACME issuance nyní rozděluje certifikáty vrácené objednávkou na leaf-only certificate data a normalizovaný issuer chain. Tím se zabrání tomu, aby se plný ACME bundle ukládal dvakrát nebo byl interpretován současně jako aktuální certifikát i chain.
ACME bridge finalizace validuje CSR identifikátory a persistuje async ADCS certifikáty — MazeVault ACME server nyní odmítá finalize CSR, jehož DNS/IP identifikátory nejsou součástí ACME objednávky, konzistentně používá RFC 8555 certificate URL path a vytvoří sledovaný Certificate záznam, když ADCS-backed ACME objednávka doběhne po schválení CA managerem.
External CA polling správně řeší DCV, pending objednávky i stahování certifikátů — External CA order poller nyní počítá jako dokončenou práci pouze skutečně vyřešené objednávky, fetchuje a ukládá DCV tokeny, když provider vyžaduje validaci, stahuje certificate bundle pro DigiCert a SSLMarket před finalizací a request-originated objednávky dokončuje atomicky napříč záznamy certifikátu, queue, requestu a přiřazení agenta.
DCV retry už předčasně neresumuje expirované challenge — Operátorský DCV retry před znovunačtením provider instrukcí resetuje expirované nebo stale challenge, bezpečně funguje i bez audit service v testovacím/background kontextu a nechá queue item ve stavu pending_dcv, pokud stále existují expirované tokeny, místo aby nesprávně pokračoval ke stažení certifikátu.
ADCS DCOM odpovědi přijímají numerické i textové stavy — Backend DCOM parser nyní přijímá legacy numerické ADCS disposition kódy i agent odpovědi jako pending, issued nebo denied, takže zachovává dosavadní chování a zároveň umožňuje bezpečně sjednotit agent/backend kontrakt.
Obnovené certifikáty zachovávají podkladovou interní signing CA — Renewaly přes interní organizační CA účet nyní zachovávají ID podkladové CertificateAuthority na obnoveném certifikátu a zároveň dál podepisují přes nakonfigurovaný CA account provider. Renewaly přes externí CA účty interní CA pole nadále nevyplňují.
Audit approval continuation obsahuje rotační kontext — Automatické pokračování rotace po approval nyní zapisuje audit události s projektem rotačního intentu a iniciátorem, pokud je dostupný. Zlepšuje to dohledatelnost bez změny idempotence continuation toku nebo vynucení approval.
Inference HSM algoritmu u interní CA je krytá regresními testy — Interní CA HSM signer nyní používá čistší type switch pro inference RSA, RSA-PSS a ECDSA algoritmů a testy pokrývají očekávané JWA mapování.
Terraform update write-only secretů už při změně metadat znovu neposílá ani nerotuje hodnotu — Metadata nebo TTL update Terraformem spravovaného mazevault_secret, který používá value_wo, nyní volá backend bez plaintext hodnoty, pokud se nezmění value_wo_version. MazeVault proto při metadata-only apply zachová existující secret material, historii verzí, offload stav, stav externího provideru i propagaci. Explicitně prázdné hodnoty secretu jsou odmítnuty místo toho, aby se zaměnily za vynechané hodnoty.
Terraform CA account provider typy se validují konzistentně — Terraform resource mazevault_ca_account nyní odmítá prázdné, whitespace-only, mixed-case a nepodporované hodnoty provider_type ještě před voláním backend API. Akceptované kanonické hodnoty jsou sladěné s backend CA account resolvery, které se umí skutečně připojit, včetně internal, SSLMarket aliasu rapidssl a venafi; placeholder integrace I.CA/PostSignum a PSD2 zůstávají vyřazené, dokud backend nezačne hlásit connectable stav. Venafi account-backed provider resolution je nově zapojený v obou servisních cestách CA účtů, takže dokumentované Venafi CA účty už neselhávají v organization CA-account resolveru. Stávající dokumentované konfigurace s lowercase hodnotami fungují beze změny.

Poznámky k migraci¶

Migrace 000189_fix_secret_version_null_uuid opravuje neplatné hodnoty secret_versions.id tak, že chybějící nebo nulové UUID nahradí nově vygenerovanými UUID. Jde pouze o opravu dat a nemění veřejné API kontrakty.
Migrace 000190_sync_problem_actions přidává permission sync:write do oprávněných systémových rolí a vytváří tabulku sync_problem_dismissals pro trvalé acknowledgement aktuálních sync failure fingerprintů. Migrace je idempotentní a nemění konfigurační schéma ani environment proměnné.

Poznámky¶

Dopad upgradu — Verze 1.0.59 obsahuje dvě databázové migrace: 000189_fix_secret_version_null_uuid pro opravu legacy UUID v historii verzí secretů a 000190_sync_problem_actions pro sync remediation oprávnění a per-fingerprint dismissal tabulku. Přibývají sync-specific API endpointy pro acknowledgement aktuálních sync failures a blocked seed incidentů; nevyžadují nové environment proměnné ani změny formátu release balíčku. Terraform write-only hodnoty secretů vyžadují Terraform 1.11+, pokud se value_wo používá s ephemeral vstupy; existující konfigurace s value a generate fungují dál. Update secretu nyní přijímá metadata/TTL-only požadavky bez vytvoření nové verze, což je rozšíření kompatibility API. Refresh pohledů rotace secretů je frontend-only změna a oprava zobrazení autora v historii verzí je backend servisní změna bez konfiguračního dopadu. Změny certificate chainu, exportu, ACME, external CA DCV, async issuance nových requestů, CA account settings, renewalu, auditu approval continuation, HSM, SDK a Terraform provideru nepřidávají žádné další migrace, environment proměnné, Helm values ani změnu formátu release balíčku. Terraform validace CA account provider typů nyní odmítá neplatné hodnoty dříve; dokumentované lowercase konfigurace provider_type fungují dál. CertificateRequest.status může nově vracet submitted_to_ca, pokud request přes externí CA čeká na DCV/provider issuance, a nové renewal queue DCV endpointy používají existující certificate RBAC permissions.

Verze 1.0.58¶

Datum vydání: 2026-07-16

Nové funkce¶

ACME challenge policy na šablonách certifikátů — Šablony certifikátů nyní obsahují pole challenge_type (auto, dns-01, http-01, tls-alpn-01, výchozí auto), které řídí způsob ACME validace, pokud je vydávající CA účet ACME provider (Let's Encrypt, ZeroSSL, vlastní ACME). Politika se vynucuje při vydávání: dns-01 vyžaduje nakonfigurovaný DNS solver a bez něj rychle selže, http-01 odmítne wildcard identifikátory (které ACME přes HTTP neumí ověřit) a tls-alpn-01 vrací jasnou chybu „nepodporováno“ místo tichého fallbacku. auto zachovává původní chování (wildcard → DNS-01 při dostupném solveru, jinak HTTP-01). Pole je dostupné v průvodci certifikátů v Project Templates, v detailu šablony a přes Terraform provider (mazevault_certificate_template.challenge_type). U neACME vydavatelů (interní CA, DigiCert, ADCS, …) se ignoruje.
ACME atributy v Terraform provideru — Resource mazevault_ca_account nyní podporuje ACME pole email, directory_url, eab_kid a eab_hmac_key (HMAC klíč je označen jako citlivý/write-only). Mapují se do šifrovaného úložiště credentials na backendu a umožňují Terraformem spravované účty Let's Encrypt, ZeroSSL a vlastní/EAB ACME. Stávající atributy api_key/base_url zůstávají pro API-style providery. Provider nyní posílá backend-kompatibilní kontrakt credentials/display_name místo dřívějšího generického config, a write-only credentials se při čtení zachovávají (žádný falešný drift).

Vylepšení¶

Jedna interní CA — ucelený životní cyklus a správa — Interní certifikační autorita organizace se nyní spravuje jako jediný prvotřídní objekt v Organization Settings → Project Settings → Certificate Authorities → Internal Certificate Authority. Nové endpointy interní CA vyhledají, inicializují a opraví (GET/POST /organizations/{id}/internal-ca, POST /organizations/{id}/ca-accounts/{accountId}/initialize-ca) a vytvoření druhého interního rootu je odmítnuto (guard jedné CA). UI nabízí akci Initialize Internal CA (common name, velikost klíče, platnost) a opravnou akci Initialize CA pro interní účty dříve vytvořené bez klíčového materiálu. OCSP/CRL URL jsou editovatelné a regenerace CRL je dostupná přímo z karty interní CA. Agenti nadále beze změny distribuují certifikát CA do trust store serverů.
„Add CA Account“ je nyní pouze pro externí CA — Tok Add CA Account už nenabízí volbu Internal (která dříve vytvořila nefunkční „prázdný“ účet bez klíčového materiálu). Správa interní CA je výhradně v sekci Internal Certificate Authority. Interní CA je vyfiltrována z karet externích CA účtů, aby se nezobrazovala dvakrát, přičemž zůstává plně vybíratelná všude jinde (projektové integrace, vazba CA v šablonách, ACME/EAB dialogy).
Striktní enforcement renewal: Template + CA povinný — Pipeline pro obnovu certifikátů nyní vyžaduje, aby každý certifikát měl přiřazený TemplateID a aby přiřazená šablona měla nastavený CAAccountID. Certifikáty bez šablony nebo se šablonou bez CA účtu jsou odmítnuty s jasnou chybovou zprávou na vstupu do pipeline. Toto odstraňuje předchozí víceúrovňový fallback řetězec pro vyhledání CA (cert-level CA, project overrides, výchozí internal CA) a stanovuje template.CAAccountID jako jediný zdroj pravdy pro výběr CA při obnově.

Opravy chyb¶

Interní CA se už nehlásí jako „nenalezena“, když existuje — Záložka Certificate Authorities dříve pro zobrazení interních CA procházela CA vázané na projekty, takže org-level interní CA (bez vazby na projekt) byla neviditelná a sekce vždy ukazovala „No internal CAs found“. Sekce nyní vyhledá interní CA přes vazbu interního CA účtu organizace a správně ji zobrazí včetně OCSP/CRL konfigurace.
OCSP/CRL konfigurace se ukládá i pro org-level interní CA — Editace OCSP/CRL URL interní CA nyní používá endpoint na úrovni CA (PUT /ca/{id}) místo project-scoped cesty, která neuměla adresovat org-level CA (project_id = NULL). OCSP zůstává záměrně jen pro interní CA — externí CA (DigiCert, Let's Encrypt, ZeroSSL) nadále inzerují vlastní OCSP/CRL respondery přes vložené AIA/CDP ukazatele.
Dopad na integrace při mazání nyní ignoruje soft-deleted secrety — Raw SQL agregace za affectedSecretCount a collectOrphanedSecretIDs filtrovaly pouze archived_at IS NULL a ignorovaly GORM soft-delete (deleted_at). To mohlo nafouknout hlášený počet „celkem dotčených“ / osiřelých secretů oproti všem ostatním cestám, které se na secrets dotazují přes GORM (a deleted_at IS NULL doplní automaticky). Oba raw dotazy nyní filtrují i deleted_at IS NULL, čímž se obnovuje jednotná a konzistentní množina secretů napříč výsledkem mazání, endpointem dopadu mazání, audit logem i rozpadem podle prostředí.
Rotace odloženého secretu už nehlásí refresh, který neproběhl — markDelayedSecretReauthorizing nastavoval v metadatech exekuce refresh_performed=true ještě před samotným voláním re-autorizace, takže pád nebo chyba před AuthorizeRotationConfigPublish uložily zavádějící refresh_performed=true, i když žádný refresh neproběhl. Placeholder nyní zapisuje refresh_performed=false; příznak se nastaví na true pouze na úspěšné cestě re-autorizace. Sémantika „nanejvýš jednou“ zůstává beze změny — loop guard se opírá o refresh_attempted + refresh_generation.

Odstranění¶

ProjectCAOverride odstraněn — Tabulka project_ca_overrides a veškerý přidružený kód (model, handlery, servisní metoda findProjectCAOverride) byly odstraněny. Tato funkce nebyla nikdy zpřístupněna přes API router (routes nebyly registrovány) a tabulka byla v produkci vždy prázdná. Renewal orchestrator nyní vyhledává CA výhradně ze šablony. Migrace 000188 odstraňuje tabulku.
buildTemplateFromCert odstraněn — Syntetický fallback pro certifikáty bez šablony byl odstraněn. Certifikáty musí mít přiřazenou řádnou šablonu, než je lze obnovit.

Údržba¶

Odstraněno mrtvé PKI UI — Tři osiřelé, nedosažitelné frontend komponenty byly smazány po ověření, že nedojde ke ztrátě funkce: CAManagementTab (jeho funkce Initialize CA / HSM / CRL nahrazuje sekce Internal Certificate Authority) a CertificateTemplatesTab + CertificateTemplateModal (nahrazeno variable-driven tokem certifikátů v Project Templates, který pokrývá subject DN a SAN přes proměnné šablony). Živý CertificateTemplateViewModal (používaný záložkou Templates v projektu) je zachován.
Opraven komentář v hlavičce migrace 000188 — Komentář v hlavičce 000188_drop_project_ca_overrides.up.sql chybně odkazoval na „Migration 000187“; nyní správně uvádí „000188“. Bez funkční změny.

Poznámky k migraci¶

Migrace 000188_drop_project_ca_overrides odstraňuje tabulku project_ca_overrides. Jedná se o nedestruktivní změnu, protože tabulka nikdy nebyla naplněna aplikací (API routes nebyly nikdy zaregistrovány).
Certifikáty bez TemplateID, které se dříve spoléhaly na fallback na interní CA, budou nyní v dashboardu rotací vykazovat stav „no template assigned" a nemohou se automaticky obnovovat, dokud jim nebude přiřazena šablona.

Poznámky¶

Dopad upgradu — Verze 1.0.58 přidává dvě databázové migrace: 000182_add_challenge_type_to_certificate_templates (přidává do certificate_templates sloupec challenge_type VARCHAR(20) DEFAULT 'auto' s CHECK omezením) a 000188_drop_project_ca_overrides (odstraňuje vždy prázdnou tabulku project_ca_overrides). Obě migrace jsou idempotentní a zpětně kompatibilní; existující šablony defaultují na auto a stávající chování ACME vydávání se nemění. Žádné změny konfiguračního schématu.
Terraform provider — Stávající konfigurace mazevault_ca_account fungují dál; nové ACME atributy jsou volitelné. mazevault_certificate_template získává volitelný atribut challenge_type s výchozí hodnotou. Interní CA se záměrně nespravuje přes Terraform — spravuje se v UI MazeVault.

Verze 1.0.57¶

Datum vydání: 2026-07-07

Opravy chyb¶

Synchronizační kroky rotace (pre/post_rotation_sync) nyní používají managed identity místo zastaralých credentials z konfigurace — Když kroky pre_rotation_sync nebo post_rotation_sync orchestrátoru rotace rozpoznávaly Azure credentials přes getAzureCredentialFromConfig, funkce automaticky detekovala pole client_secret ze zašifrovaného konfiguračního blobu integrace, i když byla integrace nakonfigurována s background_auth_method=managed_identity. To způsobovalo chyby AADSTS7000215 (neplatný client secret) během synchronizačních kroků rotace, zatímco identické připojení ke Key Vaultu úspěšně procházelo během nesouvisejících synchronizačních cest. Credential helper nyní preferuje systémovou managed identity, pokud je auth_method prázdný a systém má nakonfigurovanou MI, čímž zabraňuje zachycení zastaralých SSO app credentials. Navíc vrstva delegování přes gateway již neblokuje delegaci pouze kvůli přítomnosti managed identity a delegované synchronizační kroky nyní nesou snapshot secret_metadata, takže gateway-prováděné synchronizační kroky mohou rozpoznat cílový klíč secretu bez nutnosti přímého databázového dotazu.
Delegování přes gateway již není blokováno přítomností managed identity — canDelegateEnvironment() dříve bezpodmínečně vracelo false, pokud credential factory hlásila dostupnost managed identity, čímž bránilo jakémukoliv delegování synchronizace Azure KV na gateway v prostředích s nakonfigurovanou MI. Tato brána byla odstraněna; delegování přes gateway nyní závisí výhradně na párování prostředí a dostupnosti gateway, což umožňuje správné delegování synchronizačních operací autentizovaných přes MI.
Rotace v orchestrator mode již neprovádí duplicitní zápis do Key Vault — V orchestrator mode (storage_mode=names_only) krok mazevault_secret dříve volal SecretService.Update, který interně posílal novou hodnotu do externího trezoru přes PushSecretToEnvironment. Protože post_rotation_sync zasílá tutéž hodnotu do trezoru také, každá rotace produkovala nadbytečný duplicitní zápis. Krok nyní v orchestrator mode volá pouze BumpVersion() (lokální inkrementace čítače verze) a jedinou externí zápis přenechává kroku post_rotation_sync.
Compensate kroku mazevault_secret v orchestrator mode již neselhává na prázdném EncryptedValue — Když rotační sága prováděla rollback kroku mazevault_secret v orchestrator mode, Compensate() se pokoušel dešifrovat EncryptedValue předchozí verze, které je pro secrety names_only vždy NULL/prázdné. To způsobovalo falešné stavy „partially_rolled_back". Cesta kompenzace nyní pro orchestrator-mode secrety ihned vrací nil — rollback hodnoty v externím trezoru zajišťuje PostRotationSyncStep.Compensate, který má per-integration snapshot před přepsáním.
Pre-rotation sync již v orchestrator mode neprovádí zbytečný round-trip hodnoty zpět do Key Vault — Když pre_rotation_sync detekoval novější hodnotu v Azure Key Vault, volal UpdateSecret, který v orchestrator mode posílal tutéž hodnotu rovnou zpět do trezoru (redundantní síťové volání). V orchestrator mode krok nyní zachytí hodnotu z KV jako kontext previous_value pro následující kroky bez spouštění zápisu do lokální DB nebo externího pushe.
Discovery report agenta tiše nezapisoval aktualizaci metadat — ProcessDiscoveryReport() ukládal nalezené certifikáty do databáze, ale nikdy neaktualizoval metadata samotného agenta (last_discovery_at, discovered_certificates_count). Po úspěšném discovery běhu zůstal řádek agenta zastaralý, takže operátoři nemohli z dashboardu zjistit, zda agent kdy provedl discovery ani kolik certifikátů nalezl. Transakce nyní končí atomickým count dotazem a aktualizací řádku agenta, takže statistiky na dashboardu odrážejí realitu ihned po každém reportu.
Verze agenta se neukládala z health heartbeatu — UpdateHealth() ukládal celý health payload do JSONB sloupce health_status a obnovoval last_seen, ale nikdy neextrahoval řetězec agent_version do jeho dedikovaného sloupce. Agenti hlásící svou verzi přes heartbeat se v UI zobrazovali jako verze-neznámá. Handler nyní kopíruje agent_version z health mapy do modelu agenta před uložením.
Prázdný dropdown prostředí v dialogu Bind Agent — Dialog „Bind Agent" na záložce Project Integrations načítal data prostředí z GET /projects/:id/environment-settings (který vrací ProjectEnvironmentSetting[] s polem environment), ale vykresloval seznam s očekáváním objektů Environment[] (s poli slug a name). Protože se názvy polí neshodovaly, každá položka dropdownu se zobrazovala prázdná. Dialog nyní načítá z GET /organizations/:orgId/environments, který vrací správný tvar Environment[], a dropdown se tak správně naplní.

Verze 1.0.56¶

Datum vydání: 2026-07-01

Vylepšení¶

Rozšířené bezpečnostní gate v release pipeline — Vývojová CI pipeline nyní skenuje všechny dodávané image včetně docs a init-certs a release pipeline nově skenuje i docs a při nálezech Trivy se závažností CRITICAL/HIGH release ukončí chybou místo pasivního reportingu. Uzavírá se tím slepé místo, kdy pomocné image mohly projít do vydání s neopravenými zranitelnostmi, i když backend, frontend a ocsp byly čisté.
Sjednocení base image a lokálního runtime — init-certs se nyní v lokálním docker-compose builduje ze stejného připnutého Dockerfile.init-certs místo ad-hoc bootstrapu nad alpine:latest. Image init-certs přešla na Alpine 3.21 s upgradem balíčků během buildu a runtime stage docs image nyní před zabalením nginx obnovuje Alpine balíčky. Tím se snižuje drift mezi CI artefakty a lokálním během a zároveň expozice známým CVE v OS balíčcích.
Obnova backend závislostí pro dosažitelné integrační cesty — Byly připnuty opravené Go verze pro github.com/Azure/go-ntlmssp, github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream, github.com/aws/aws-sdk-go-v2/service/s3, github.com/quic-go/quic-go a go.mongodb.org/mongo-driver, což pokrývá dosažitelné volitelné cesty jako ADCS NTLM autentizaci, transport auditního archivu do S3, použití QUIC stacku a MongoDB reconciliaci a rotační kód.

Opravy chyb¶

Request ID tracing sjednocen napříč middleware a logy — RequestIDMiddleware nyní plní oba Gin context klíče requestID i legacy request_id a dál vrací hlavičku X-Request-ID; warning logy rozlišení prostředí současně čtou kanonický klíč requestID. Tím se uzavírá mezera ve sledovatelnosti, kdy část logů zapisovala prázdné request ID, přestože už bylo požadavku přiřazeno.
Orchestrator mode guard používá přesné route patterny — Ingress guard v orchestrator mode už nespoléhá na heuristiky nad suffixy a substringy URL. Místo toho páruje registrované Gin route patterny přes c.FullPath() pro write route secretů v /api/v1/secrets i /api/v2/secrets a současně se vyhýbá false positive zásahům do vnořených flow, jako je import certifikátů. Přímé payloady secretů s polem value zůstávají v orchestrator mode blokované, ale legitimní endpointy pro import certifikátů už nejsou ohroženy náhodným zachycením.
Synchronizace Entra pro vybrané aplikace nyní zůstává ve stavu pending, dokud neexistují bindingy — Pokud je Entra integrace nakonfigurována se scope selected_apps, ale zatím k ní nejsou uloženy žádné bindingy vybraných aplikací, manuální synchronizace nyní vrací HTTP 409 Conflict místo obecného selhání. Integrace se zapíše s last_sync_status = pending, last_sync_error zůstane prázdné a hodinový plánovač jen zaloguje přeskočení, dokud není nakonfigurována alespoň jedna vybraná aplikace. API i provozní stav tak pravdivě odrážejí postupný onboarding.
Stavy synchronizačních pravidel a auditní metadata nyní zachovávají provenienci spuštění — Běhy synchronizačních pravidel nyní persistují kanonický execution záznam a promítají výsledné execution_id, trigger_source, zdrojový secret/prostředí a agregované počty výsledků do stavových polí pravidla i metadat synchronizačních logů. Obousměrná synchronizace navíc potlačuje okamžitý echo-push secretů, které byly právě nataženy nebo zůstaly po pull fázi beze změny, čímž omezuje zbytečný churn v externím systému a zároveň drží sync_rules.last_sync_status a project_integrations.last_sync_* v souladu s finálním výsledkem.
Krok 0 rotace (connection_validation) nyní respektuje background_auth_method integrace — Když orchestrátor rotace provádí operaci lokálně (nedelegovaná cesta), metoda TestConnection() pro integrace Azure Key Vault nyní volá prepareAzureIntegrationRuntimeConfig() před pokusem o připojení. Dříve zastaralé přihlašovací údaje client_secret v zašifrované konfiguraci integrace přebíjely nakonfigurovanou hodnotu background_auth_method=managed_identity, což způsobovalo chyby ClientSecretCredential authentication failed během rotace, zatímco synchronizace (která již používala správnou přípravnou cestu) úspěšně pokračovala. Oprava zajišťuje konzistentní rozlišení autentizační metody napříč cestami synchronizace a rotace.

Poznámky¶

Dopad upgradu — Verze 1.0.56 neobsahuje databázové migrace ani změny konfiguračního schématu. Stávající API kontrakty zůstávají stabilní; hlavní provozní změnou je přísnější release gating, takže CI a release joby nyní mohou selhat, pokud image docs nebo init-certs obsahují nevyřešené nálezy se závažností CRITICAL/HIGH.
Dopad na lokální vývoj — První docker compose up --build po upgradu znovu sestaví dedikovanou image client-init-certs místo stažení generické Alpine base a inline instalace balíčků. Build může být mírně delší, ale lokální chování nyní mnohem přesněji odpovídá dodávané image.

Verze 1.0.55¶

Datum vydání: 2026-06-29

Nové funkce¶

Správa cílů rotace secretů (Secret Rotation Targets) — Plná CRUD správa cílů rotace secretů je nyní dostupná přes API, frontend, Go SDK a Terraform. Cíle definují cílová umístění nasazení (Kubernetes secrets, rotace databázových hesel, synchronizace agenta, proměnné DevOps pipeline, cloudové trezory), do nichž MazeVault zasílá aktualizované přihlašovací údaje ihned po dokončení rotace. Nová komponenta SecretRotationTargetList na záložce Secrets umožňuje operátorům přidávat, upravovat a odstraňovat cíle bez opuštění pohledu projektu. Terraform resource mazevault_secret_rotation_target umožňuje plně deklarativní správu; argument config_json přijímá JSON objekt zakódovaný pomocí jsonencode() popisující konfiguraci specifickou pro daný cíl.
Aktualizace konfigurace interní CA a doplnění AIA (Backfill) — Dva nové API endpointy umožňují aktualizovat měnitelná pole na účtu interní CA bez nutnosti jeho opětovného vytvoření: PUT /api/v1/ca/:id a PUT /api/v1/projects/:id/ca/:caId přijímají ocsp_url, crl_url a ocsp_responder_cert_id s patch sémantikou (vynechaná pole zůstanou nezměněna). Doprovodný endpoint POST /api/v1/admin/certificates/backfill-aia zpětně kopíruje aktuální OCSP a CRL URL z účtu CA do všech existujících certifikátů, které vydal. Rozšíření OCSP URL, CRL Distribution Points a Issuer Certificate URL jsou nyní správně vkládána do šablony x509 v rámci InternalCAProvider.SignCSR() pro všechny nově vydávané certifikáty.
Výběr agenta v konfiguraci rotace — SecretPostRotationActionsPanel a SecretRotationTargetEditor nyní zobrazují rozbalovací nabídku, která operátorovi umožňuje svázat konkrétního registrovaného agenta s cílem rotace. Tím je zajištěna přesná kontrola nad tím, který on-premise agent provede krok nasazení, bez nutnosti spoléhat se výhradně na směrování dle prostředí.
Modal pro zobrazení šablony certifikátu — Nová komponenta CertificateTemplateViewModal poskytuje podrobné zobrazení šablony certifikátu jen pro čtení (SAN vzory, key usage, extended key usage, platnost, vazba na CA účet) bez nutnosti opustit aktuální stránku. Modal je přístupný jak ze záložky CertificateTemplatesTab na úrovni organizace, tak ze záložky TemplatesTab na úrovni projektu. Zobrazení nyní také ukazuje algoritmus podpisu (s návratem na výchozí hodnotu CA, pokud není nastaven) a název ACME profilu a označuje omezení sloužící pouze k validaci a pole řízená externí CA, takže operátoři rozumí tomu, která nastavení vynucuje MazeVault a která vydávající CA.
Šablony certifikátů nyní řídí vydávání od začátku do konce — Šablony certifikátů byly povýšeny z částečně dekorativního metadatového záznamu na autoritativní governance „kuchařku" pro vydávání certifikátů v celém životním cyklu. Pole šablony, která byla dříve ukládána, ale nikdy aplikována, jsou nyní respektována podpisovým enginem a generátorem CSR: max_path_length (s explicitním zpracováním path-length-zero pro CA certifikáty), policy OID certifikátů (policy_identifiers / certificate_policies), signature_algorithm, výchozí šablona common-name (cn_template) a subjektový email. Nová záložka Governance v CertificateTemplateModal zpřístupňuje požadavky na schválení, povolená prostředí a povolené velikosti klíčů a vyhrazená sekce Renewal & Rotation umožňuje nezávisle nastavit politiku opětovného použití klíče. Výchozí hodnoty šablon jsou nyní normalizovány při vytvoření/aktualizaci (validity_days → 365, key_size → 256/2048 dle algoritmu, okna minimální/maximální platnosti), takže šablona nikdy nemůže uložit neúčinné nulové hodnoty.
Modaly pro zobrazení šablon projektů a konfigurací — Dva nové modaly s detailem jen pro čtení, ProjectTemplateViewModal a ConfigTemplateViewModal, přinášejí stejný způsob rychlé inspekce, který je již dostupný pro šablony certifikátů, i k šablonám projektů (obecná nastavení, pravidla prostředí, schéma proměnných, konfigurace protokolu) a šablonám konfigurací (metadata, souhrn definice, surový JSON). Oba jsou dostupné přes akci zobrazení (ikona oka) v příslušných záložkách správy.
Terraform: Certificate Rotation Config, Entra Rotation Config a datový zdroj Rotation Resources — Tři nové Terraform povrchy doplňují IaC pokrytí rotační platformy: mazevault_certificate_rotation_config spravuje plánování automatického obnovení a seznamy akcí po rotaci pro konkrétní certifikát; mazevault_entra_rotation_config spravuje nastavení rotace přihlašovacích údajů Entra ID včetně prahu dní před expirací a chování postupné rotace; mazevault_rotation_resources je datový zdroj, který vypisuje všechny rotací spravované zdroje s jejich aktuálním stavem, filtrovatelný podle kind a environment_scope.

Reforma identity prostředí¶

Identifikátory prostředí jsou nyní ukládány doslovně a párovány přesně — Identifikátory prostředí zadané v Nastavení organizace jsou jediným zdrojem pravdy. Systém je nyní ukládá doslovně (se zachováním velikosti písmen) a páruje je přesně (s ohledem na velikost písmen) všude — RBAC, secrety, synchronizační pravidla, směrování gateway, úlohy gateway, zámky prostředí i frontend. Identifikátory, které se liší pouze velikostí písmen (například developmentA, DeveLopmentB, DeveLopmentC), jsou považovány za odlišná prostředí. Systém nikdy tiše nepřepisuje, nepřevádí na malá písmena, neořezává ani nemapuje aliasy toho, co operátor zadal.
CanonicalizeEnvironment je nyní pouze validační: odmítá prázdné/jen z mezer složené, rezervované (*, default, all, system, none), příliš krátké/dlouhé a chybně tvarované identifikátory (povolený tvar ^[A-Za-z][A-Za-z0-9_-]{1,31}$) a při úspěchu vrací vstup beze změny.
Mapa aliasů prostředí gateway (pro→production, npr→nonproduction atd.) byla odstraněna z backendu i frontendu. SupportsEnvironment(), GetEnvironmentMode(), směrování gateway, failover health-monitoru a frontendový pomocník environments nyní porovnávají identifikátory přesně. Frontendový pomocník prostředí již neaplikuje toLowerCase()/normalizaci tokenů a všechny selektory prostředí získávají své volby výhradně ze seznamu prostředí organizace.
Dopad: existující data prostředí zákazníků jsou jednotně malými písmeny, takže přesné párování dle velikosti písmen je pro stávající záznamy no-op — nulová regrese RBAC/secret/sync. Identifikátory se smíšenou velikostí písmen jsou podporovány pouze do budoucna.

Vylepšení¶

Úplnost prověření před spuštěním rotace (gateway, agent a runtime Entra) — Orchestrátor rotace nyní ověřuje, že každý požadovaný cíl provedení je dosažitelný před prvním mutujícím krokem, a vrací strukturovanou chybu HTTP 412, pokud rotaci nelze bezpečně zahájit. Místo neprůhledné chyby 500/409 jsou nyní zobrazovány tři nové chybové kódy — rotation_blocked_no_gateway, rotation_blocked_agent_offline a rotation_blocked_runtime_unavailable. Prověření nyní zohledňuje certifikáty (správně rozpozná cíle CertificateRotationConfig), shromažďuje všechna požadovaná ID agentů napříč všemi kroky workflow využívajícími agenta a je vynucováno také uvnitř executeCertificateWorkflow. Rotace přihlašovacích údajů Entra spouští stejné prověření runtime v RotateCredentialWithRequest dříve, než životní cyklus přejde do stavu rotating, takže blokovaný runtime nikdy nezanechá přihlašovací údaj rotovaný jen napůl. Změna přihlašovacího údaje nebo certifikátu, kterou nelze nasadit, nyní selže rychle a viditelně namísto toho, aby se spustila a zasekla.
Delegování synchronizace Azure Key Vault přes gateway — Operace synchronizace push a pull s Azure Key Vault jsou nyní delegovány na příslušnou gateway, pokud backend zjistí, že přímá síťová cesta k endpointu Key Vault není dostupná. Úlohy gateway nesou konfiguraci integrace a provádějí skutečná volání Azure SDK; primární backend zaznamenává pouze výsledný stav synchronizace. Spuštění plánovače synchronizačních pravidel bylo odloženo až po úplné inicializaci delegování přes gateway, čímž se zamezuje přechodným chybám DNS při startu backendu.
Automatické doplnění cílového prostředí v konfiguraci rotace — Když GetConfigBySecretID vytváří novou konfiguraci rotace pro secret, který ji dosud nemá, pole target_environment je nyní automaticky doplněno z prostředí daného secretu. Tím odpadá ruční krok aktualizace, který byl dříve vyžadován před prvním spuštěním rotace.

Opravy chyb¶

Párování prostředí gateway přepracováno na doslovnou/přesnou identitu — Dříve v tomto vydávacím cyklu se párování prostředí gateway spoléhalo na mapu aliasů bez ohledu na velikost písmen (pro→production, npr→nonproduction atd.), která mohla tiše mapovat nesouvisející identifikátory dohromady a mutovat hodnoty zadané operátorem. Tento přístup byl nahrazen doslovným/přesným modelem identity prostředí (viz Reforma identity prostředí výše): SupportsEnvironment() a GetEnvironmentMode() nyní porovnávají přesně, mapa aliasů byla odstraněna a dříve plánovaná migrace normalizace aliasů 000176 byla neutralizována na no-op (nikdy nebyla dodána zákazníkům). Dopředné migrace 000178/000179 odstraňují CHECK constrainty vynucující malá písmena a unikátní indexy bez ohledu na velikost písmen, takže jsou přijímány identifikátory lišící se velikostí písmen.
Rozšíření AIA nevkládána do vydávaných certifikátů — InternalCAProvider.SignCSR() načítalo ocsp_url a crl_url ze záznamu CA, ale nikdy je nezapisovalo do šablony certifikátu x509, takže každý certifikát vydaný interní CA měl prázdná rozšíření Authority Information Access a CRL Distribution Points. Obě rozšíření jsou nyní správně vkládána do všech nových certifikátů. Existující certifikáty lze zpětně aktualizovat prostřednictvím nového backfill endpointu.
Device Fingerprint — souběžná podmínka (race condition) při vkládání — Služba detekce anomálií mohla produkovat porušení constraints s duplicitním klíčem, pokud se dvě souběžné autentizační požadavky od stejného dříve neviděného zařízení pokoušely současně zaregistrovat jeho otisk. Cesta vkládání nyní používá upsert vzor s ochranou ON CONFLICT DO NOTHING pro korektní zpracování souběžných registrací.
Plánovač synchronizačních pravidel — chyby DNS při startu backendu — Na backendech nakonfigurovaných s delegováním přes gateway mohlo první naplánované spuštění plánovače synchronizačních pravidel selhat s chybami DNS, protože se spustil dříve, než subsystém delegování gateway dokončil inicializaci. Spuštění plánovače je nyní odloženo až po připravenosti delegační vrstvy.
Terraform resource organizace — tiché spolknutí chyb při mazání — Metoda Delete v Terraform resource mazevault_organization vracela úspěch i v případě, kdy backend odpověděl stavovým kódem jiným než 2xx. Chyby backendu jsou nyní zobrazovány jako Terraform diagnostiky, takže terraform destroy viditelně selže namísto ponechání resource v nekonzistentním stavu.
Policy OID certifikátů tiše vynechány z vydaných certifikátů (Go 1.24+) — InternalCAProvider.SignCSR() vyplňoval pouze zastaralé pole x509.Certificate.PolicyIdentifiers. Go 1.24+ x509.CreateCertificate vydává rozšíření Certificate Policies místo toho z nového pole Policies ([]x509.OID), takže policy OID deklarované v šabloně byly tiše vynechány z každého vydaného certifikátu. SignCSR nyní vyplňuje obě pole — moderní slice Policies (pro současné enkodéry) i legacy slice PolicyIdentifiers (pro starší parsery) — takže policy OID jsou spolehlivě vkládány.
Podpisová a subjektová pole šablony certifikátu byla neúčinná — max_path_length, signature_algorithm, policy OID certifikátů, výchozí šablona common-name a subjektový email byly v šablonách certifikátů ukládány, ale nikdy se nedostaly do vydaného certifikátu ani vygenerovaného CSR. Všechna tato pole šablony jsou nyní aplikována při podpisu a generování CSR, čímž se uzavírá rozdíl mezi tím, co šablona deklaruje, a tím, co certifikát skutečně obsahuje.
Import šablony z externí CA ukládal nulové validity_days / key_size — Šablony importované z externích poskytovatelů CA (ADCS, SmallStep) byly ukládány s validity_days = 0 a key_size = 0, což se následně projevovalo jako neplatné výchozí hodnoty v editoru šablon. Importované šablony nyní nesou rozumné výchozí hodnoty (key_size = 2048, valid_days = 365) a servisní vrstva normalizuje veškeré zbylé nulové hodnoty při vytvoření/aktualizaci jako obranu do hloubky.

Databázové migrace¶

000176_normalize_gateway_environments — Neutralizováno na no-op (SELECT 1). Tato migrace původně normalizovala legacy aliasy prostředí na kanonické identifikátory, ale reforma identity prostředí tento směr obrátila (identifikátory jsou nyní ukládány doslovně). Protože migrace nebyla nikdy vydána žádnému zákazníkovi, jsou nyní její .up.sql i .down.sql zdokumentované no-opy, které ponechávají data gateway zákazníků nedotčená.
000177_certificate_templates_signature_algorithm — Přidává sloupec signature_algorithm VARCHAR(50) do certificate_templates (idempotentní ADD COLUMN IF NOT EXISTS), aby šablony mohly fixovat algoritmus podpisu při vydávání. Odpovídající .down.sql sloupec odstraňuje. ExpectedColumns["certificate_templates"] v database_health.go byl odpovídajícím způsobem aktualizován.
000178_relax_canonical_environment_check — Odstraňuje 11 CHECK constraintů chk_*_canonical (přidaných migrací 000125), které vyžadovaly column = LOWER(column) na každém sloupci nesoucím prostředí. Tyto constrainty by odmítaly identifikátory lišící se velikostí písmen, což odporuje doslovnému kontraktu; validace na straně aplikace (CanonicalizeEnvironment) nadále vynucuje pravidla tvaru, délky a rezervovaných slov. Dolní migrace constrainty znovu přidává. Idempotentní (DROP CONSTRAINT IF EXISTS).
000179_case_sensitive_environment_indexes — Nahrazuje unikátní pojistky LOWER() bez ohledu na velikost písmen z migrace 000122 přesným unikátním indexem s ohledem na velikost písmen uniq_environments_org_slug (organization_id, slug) a obnovuje běžné vyhledávací indexy nad surovými sloupci pro každý sloupec nesoucí prostředí. Existující unikátnost na úrovni projektu (idx_project_env) je již přesná. Dolní migrace obnovuje indexy LOWER(). Idempotentní.

Verze 1.0.54¶

Datum vydání: 2026-06-27

Opravy chyb¶

Watchdog Entra přihlašovacích údajů — detekce zaseknutí trvale obcházena hodinovou synchronizací — PostgreSQL trigger trg_entra_creds_updated obnovuje updated_at = NOW() při každém UPDATE záznamu v tabulce entra_credentials, včetně zápisů do nesouvisejících polí prováděných hodinovou synchronizační smyčkou (syncedEntraCredentialUpdates). Podmínka updated_at < now() - 30min proto nebyla nikdy splněna pro žádné přihlašovací údaje, které prošly synchronizačním cyklem, a watchdog se nikdy nespustil. Nový sloupec rotation_started_at TIMESTAMPTZ (migrace 000175) je nastaven při přechodu lifecycle_state na rotating a vymazán při rollbacku nebo zotavení watchdogem. Watchdog dotaz nyní používá rotation_started_at IS NULL OR rotation_started_at < cutoff; podmínka IS NULL pokrývá přihlašovací údaje zaseknuté před aplikací migrace.
Monitor expirace Entra — chyba GORM Preload("") při každé hodinové kontrole — checkExpiringCredentials volal .Preload("") (prázdný řetězec) na GORM dotazu. GORM v2 toto odmítá chybou unsupported relations for schema EntraCredential, každou hodinu loguje chybu a zabraňuje nastavení stavu expiring_soon u přihlašovacích údajů, které skutečně expirují. Neplatné volání .Preload("") bylo odstraněno; chování je jinak nezměněno.
Sync Rule Pull — porušení FK secret_versions_created_by_fkey pro systémové aktory — SyncRuleService.executePull volá SecretService.Update s req.UserID = uuid.Nil (žádný autentizovaný uživatel). Update bezpodmínečně ukládal &req.UserID jako created_by do nového záznamu SecretVersion; GORM serializuje *uuid.Nil jako řetězec '00000000-...' namísto SQL NULL, což porušuje non-null FK odkazující na tabulku users. Oprava přidává nil-guard: created_by je nastaven na NULL, pokud volající předá zero-value UUID, v souladu s kontraktem nullable sloupce.
Azure KV Integrace — synchronizované secrets zobrazeny jako „Uloženo lokálně" — syncAzureKeyVaultLocal vytvářel a aktualizoval secrets v tabulce secrets, ale nikdy nevkládal záznam SecretIntegrationLink s link_purpose = 'sync_source'. GetSecretSyncStatus proto vrátil local_only pro každý KV-synchronizovaný secret a uživatelské rozhraní zobrazovalo „Uloženo lokálně" místo „Synchronizováno z KV". Oprava vkládá inline stejnou logiku upsert jako SyncRuleService.upsertPullLink přímo v IntegrationService pomocí s.db a clause.OnConflict, čímž se předchází závislosti napříč službami.

Vylepšení¶

Oprávnění rolí — agent:admin přidáno do rolí secret_manager a certificate_manager — Operace správy agentů (agent:admin) byly přidány do systémových rolí secret_manager a certificate_manager (migrace 000174). Operátoři vlastnící pouze jednu z těchto rolí nyní mohou registrovat a konfigurovat agenty bez nutnosti přiřazení samostatné role admin.

Databázové migrace¶

000174_agent_admin_for_managers — Uděluje oprávnění agent:admin vestavěným rolím secret_manager a certificate_manager.
000175_entra_credentials_rotation_started_at — Přidává rotation_started_at TIMESTAMPTZ do entra_credentials. Obsahuje partial index idx_entra_creds_rotation_started přes (rotation_started_at) pro stavy rotating a pending_verification.

Verze 1.0.53¶

Datum vydání: 2026-06-26

Opravy chyb¶

OCSP — existence certifikátu neověřena před staplingem — Služba OCSP odpovídala na požadavky staplingu bez ověření, zda odkazované sériové číslo v lokálním úložišti certifikátů existuje. Útočník s podělátým nebo znovu použitým sériovym číslem mohl získat platnou OCSP odpověď pro neexistující certifikát. Služba nyní ověřuje existenci certifikátu před sestavením odpovědi a pro neznámá sériová čísla vrací stav Unknown.
Krok rotace — PostgreSQL GRANT/REVOKE zranitelný SQL injekcí — rotation_steps/postgres_db.go sestavoval příkazy GRANT/REVOKE přímým řetězovým spojením jména role a seznamu oprávnění bez escapování. Jména databázových rolí jsou nyní uzavřena do dvojitých uvozovek pomocí identifikátorového escapování podle pgx, což zavírá cestu SQL injekce.
SSH klíče — ExportPrivateKey bez autorizační kontroly — ExportPrivateKey neověřoval, zda žádající uživatel má vlastnictví nebo správcovská práva na SSH klíč, před vrácením šifrovaného privátního materiálu. Handler nyní vynucuje stejnou kontrolu členství v projektu a vlastnictví jako ostatní mutation endpointy SSH klíčů.
SSH rotace — chybné mapování polí API odpovědi pro páry klíčů — Handler odpovědi SSH rotace přímo prohazoval pole páru klíčů z API odpovědi, což způsobovalo vrácení prohozeného nebo prázdného public_key a key_id po úspěšné rotaci. Mapování polí bylo opraveno.
Rotace keytabu — nestrukturované logování obcházející pipeline — Chyby rotace keytabu byly emitovány přes legacy balíček log, který obchází strukturovaný logovací pipeline a ztrácí kontextová pole požadavku. Všechna volání logů v keytab_rotation_executor.go jsou nyní směrována přes slog.
CA účty — ca_authority_id neuložen při aktualizaci — UpdateCAAccount tiše zahazoval ca_authority_id při aktualizaci existujícího CA účtu, protože pole chybělo v mapě Updates pro GORM. Pole je nyní zahrnuto a pokryto novým testem.
Drift schématu CRL / revokace — OCSP vrací 500 — Tabulky revocation_entries a certificate_revocation_lists byly vytvořeny migrací 000005 s legádními názvy sloupců (reason_code, crl_pem), které se odchylují od aktuálních názvů polí GORM modelu (revocation_reason, raw_content). GORM přidává deleted_at IS NULL ke každému dotazu; protože deleted_at v produkčním schématu chyběl, vracel celý subsystém CRL/OCSP chyby SQLSTATE 42703. Migrace 000173 přidává všechny chybějící sloupce idempotentně pomocí ADD COLUMN IF NOT EXISTS a doplní hodnoty z legádních sloupců.

Vylepšení¶

Spuštění rotace — tělo požadavku volitelné — Endpointy spouštění rotace nyní přijímají požadavky s prázdným nebo chybějícím tělem; reason se v takovém případě nastaví na "manual".
CA Interní — podepisování OCSP přes HSM odloženo s explicitní dokumentací — Podepisování OCSP odpovědí přes HSM je explicitně odloženo; kódová cesta nyní obsahuje jasně označený komentář odložení a mezitím vrací odpověď podepsanou softwarově.
Feature flags — zpříbnění režimu gateway a validace licence — features.go zpřesňuje logiku vyhodnocování gateway_mode a funkcí chráněných licencí, eliminuje třídu falešně pozitivních výsledků enabled při částečně zpracovaném payloadu licence.
SRP — dokumentace pořadí kroků MFA — Tok ověřování SRP nyní obsahuje explicitní komentář dokumentující řazení kroků MFA a zdůvodnění aktuálního pořadí TOTP/záložních kódů.
Průvodce pojmenováním secretů — kontext autentizace pro správu tokenů — SecretNamingPolicyWizard nyní předává kontext autentizovaného uživatele voláním správy tokenů, čímž opravuje potenciálně neautentizovanou cestu volání v procesu ukládání průvodce.

Databázové migrace¶

000173_fix_revocation_crl_schema_drift — Přidává chybějící sloupce do revocation_entries (crl_id, revocation_reason, updated_at, deleted_at) a certificate_revocation_lists (raw_content, updated_at, deleted_at). Doplní hodnoty z legádních sloupců reason_code a crl_pem. Plně idempotentní.

Verze 1.0.52¶

Datum vydání: 2026-06-23

Opravy chyb¶

Schéma Renewal Policy — chybějící sloupce key_reuse_enabled a validity_duration — Tabulka certificate_renewal_policies byla vytvořena migrací 000010 se sloupcem reuse_private_key; Go model byl následně přejmenován na key_reuse_enabled bez doprovodné migrace, čímž každý zápis dotýkající se tohoto pole selhal na databázové vrstvě. Migrace 000172 přidává key_reuse_enabled BOOLEAN NOT NULL DEFAULT FALSE (s doplněním hodnot z legacy sloupce reuse_private_key) a validity_duration INT NOT NULL DEFAULT 0. Stejná migrace převádí notify_emails z JSONB na TEXT pomocí třífázového přístupu (přidání TEXT staging sloupce → UPDATE přes set-returning funkci → drop JSONB sloupce → přejmenování), čímž obchází omezení PostgreSQL, které zakazuje subquery uvnitř ALTER COLUMN TYPE … USING.
Fronta obnov — sloupec certificates.organization_id neexistuje — GetRenewalQueue filtroval WHERE certificates.organization_id = ?, ale tabulka certificates obsahuje pouze project_id; organizaci lze dosáhnout přes certificates.project_id → projects.organization_id. Služba nyní provádí druhý JOIN (JOIN projects ON projects.id = certificates.project_id) a filtruje podle projects.organization_id.
SDK a Terraform Provider — sémantická neshoda notify_days_before []int — Go SDK (sdks/go/models.go) a Terraform provider (internal/resources/renewal_policy.go) deklarovaly pole notify_days_before []int, které v backendu nikdy neexistovalo. Backend ukládá prostý čárkami oddělený řetězec pod klíčem notify_emails. Obě komponenty byly přepsány na notify_emails string a byla přidána dvě nová pole key_reuse_enabled a validity_duration pro sladění s živým API kontraktem. Acceptance testy blokované pomocí t.Skip z důvodu těchto nedostatků jsou nyní aktivní.

Databázové migrace¶

000172_fix_certificate_renewal_policy_schema — Přidává key_reuse_enabled BOOLEAN NOT NULL DEFAULT FALSE (doplněno z reuse_private_key), validity_duration INT NOT NULL DEFAULT 0 a převádí notify_emails JSONB → TEXT v tabulce certificate_renewal_policies.

Verze 1.0.51¶

Datum vydání: 2026-06-22

Nové funkce¶

Potvrzení selhání rotace (Acknowledge Rotation Failure) — Operátoři nyní mohou trvale odložit (dismiss) prověřené selhání rotace z dashboardu Rotation Problems bez smazání záznamu spuštění. Nový endpoint POST /api/v1/dashboard/rotation/failures/{id}/acknowledge (RBAC: dashboard:write) zapíše acknowledged_at a acknowledged_by do řádku spuštění. Dashboard dotaz filtruje potvrzené řádky a udržuje tak přehled zaměřený na položky stále vyžadující pozornost. Uživatelské rozhraní zpřístupňuje akci „Označit jako prověřeno" v panelu detailu selhání.
Watchdog pro zaseknuté Entra přihlašovací údaje — Nový background watchdog (RecoverStuckEntraCredentials) běží každých 5 minut a resetuje Entra přihlašovací údaje zaseknuté ve stavu rotating nebo pending_verification déle než 30 minut. Zabraňuje nekonečným stálům způsobeným restartem backendu nebo zrušením goroutiny uprostřed rotace. Každé zotavení zapíše stuck_watchdog_recovered_at do záznamu přihlašovacích údajů pro auditní sledovatelnost.
Stav Entra přihlašovacích údajů — pending_verification — Constraint entra_credentials_status_check byl rozšířen o hodnotu pending_verification, kterou zapisuje RotateCredentialWithRequest po každé rotaci, jsou-li nakonfigurované downstream propagační cíle. Bez tohoto rozšíření by jakákoli rotace s propagací produkovala porušení constraintu a zanechávala by přihlašovací údaje v nekonzistentním stavu.
CA účet — počet přiřazených certifikátů — Odpovědi pro seznam a detail CA účtu nyní obsahují assigned_certificates_count, tedy počet aktivních certifikátů vydaných přes šablony certifikátů svázané s daným CA účtem. Operátoři tak okamžitě vidí aktivní záběr CA účtu bez dalšího dotazu.
Terraform Provider — User, User Role, Keytab, Project Settings, Shared Secret — Pět nových Terraform zdrojů doplňuje pokrytí providera o správu uživatelů a konfigurace projektů: mazevault_user (CRUD platformních uživatelů), mazevault_user_role (přiřazení rolí uživatelům v organizaci), mazevault_keytab (správa Kerberos keytab souborů připojených k projektu), mazevault_project_settings (projektová konfigurační nastavení) a mazevault_shared_secret (secrets sdílené napříč více projekty).

Vylepšení¶

Rotation Problems — filtr potvrzených selhání — Stránka Rotation Problems a služba platformního přehledu nyní vylučují potvrzená spuštění z počtů selhání a seznamů, a to s využitím partial indexu idx_rotation_executions_unacknowledged zavedého migrací 000170.

Databázové migrace¶

000169_entra_credentials_status_pending_verification — Rozšiřuje constraint entra_credentials_status_check o hodnotu pending_verification.
000170_rotation_execution_acknowledgement — Přidává acknowledged_at TIMESTAMPTZ a acknowledged_by UUID REFERENCES users do rotation_executions. Obsahuje partial index idx_rotation_executions_unacknowledged pokrývající pouze nepotvrzené řádky.
000171_entra_credential_stuck_watchdog — Přidává stuck_watchdog_recovered_at TIMESTAMPTZ do entra_credentials. Přidává partial index idx_entra_creds_stuck_watchdog přes (lifecycle_state, updated_at) pro dva in-flight stavy.

Verze 1.0.50¶

Datum vydání: 2026-06-21

Nové funkce¶

Šablony konfigurace rotace (Rotation Config Templates) — Nový katalog v rozsahu organizace umožňuje operátorům evidovat opakovaně použitelná nastavení rotace (interval, lead days, retention window, max. počet opakování, timeout). Spravuje se přes pět API endpointů GET|POST /api/v1/rotation/templates a GET|PUT|DELETE /api/v1/rotation/templates/{id} s RBAC (rotation:read / rotation:write). Nový Terraform zdroj mazevault_rotation_template umožňuje správu katalogu přes IaC. Šablony se na konfigurace rotace automaticky neaplikují. Frontend zpřístupňuje plnou CRUD stránku na /rotation/templates. Migrace 000168 přidává tabulku rotation_config_templates a cizí klíč template_id na rotation_configs.
Sync Rule — obousměrný režim a strategie konfliktu — SyncRuleModal nyní zobrazuje konfigurovatelný směr synchronizace (pull / push / bidirectional) a synchronizační režim (incremental / full_sync). Oba atributy jsou persistovány na straně serveru a zdokumentovány v novém Terraform zdroji mazevault_sync_rule. Operace pull-sync nyní zapisují last_pulled_at, link_purpose a external_secret_path do secret_integration_links (migrace 000167), čímž umožňují zobrazení stavového odznaku synced_from_external u secrets vytažených z externího poskytovatele.
Dry-run pro rotaci certifikátů — Záložka Rotace certifikátů nyní obsahuje tlačítko „Dry Run" vedle existující akce „Trigger Rotation Now". Dry-run provede kompletní validaci workflow rotace — včetně preflight post-rotačních akcí a gateway probing — bez potvrzení jakýchkoli změn. Příznak dry_run je propagován end-to-end přes API a všechny kroky rotace.
Post-rotační akce — přímé napojení na gateway a přepsání prostředí — PostRotationAction nyní přijímá volitelné pole gateway_id, které připne akci na konkrétní gateway a obchází routing na základě prostředí. Doprovodné pole target_environment přepisuje kontext prostředí při rozlišování cílové gateway. Obě pole jsou dostupná v Go SDK (PostRotationActionWF) i v Terraform zdroji mazevault_rotation_workflow.
Terraform Provider — Sync Rules a Rotation Templates — Dva nové Terraform zdroje pokrývají kompletní životní cyklus create/read/update/delete: mazevault_sync_rule (směr synchronizace, strategie konfliktu, transformace klíče, prefix cesty) a mazevault_rotation_template (interval, lead days, retence, politika opakování). Oba jsou registrovány v provideru a zdokumentovány v docs/resources/.
Rotation Problems — detail zobrazení selhání — Stránka Rotation Problems nyní zobrazuje detailní tabulku neúspěšných spuštění s drill-down na jednotlivé zdroje, koláčový graf rozložení podle druhu zdroje a přehled chybějících secrets. Navigace v postranním panelu zvýrazňuje sekci ikonou varování.

Vylepšení¶

Distribuovaný synchronizační semafor přes Redis — SyncRuleService nyní používá distribuovaný zámek podporovaný Redis (SET NX PX) prostřednictvím nového páru TryAcquireLock / ReleaseLock na CacheService. Pokud Redis není dostupný, služba přejde na in-process zámek pomocí sync.Map. Tím se zabraňuje duplicitním souběžným synchronizacím pro stejné pravidlo v deploymentech s více replikami.
Dry-run guard ve všech krocích rotace — Všech sedm vestavěných kroků rotace (generátor hesel, Azure Key Vault, Spring Actuator, agent command, shell script, IIS recycle, Kubernetes secret) nyní kontroluje příznak dry_run před jakýmkoli mutujícím externím voláním a místo toho vrátí náhledový výsledek.
Rozšířený rozsah validace připojení — Krok rotace connection_validation byl rozšířen na pokrytí typů providerů mimo databáze (Azure Key Vault, Kubernetes, LDAP, GitHub, GitLab, generický webhook), čímž jsou zajištěny pre-execution kontroly konektivity i pro secrets napojené na tyto integrace.
Guard pro secrets s names_only storage mode — Orchestrátor rotace nyní odmítá požadavky na rotaci secrets s storage_mode = names_only s jasnou chybovou zprávou, čímž zabraňuje zavádějícím záznamům o spuštění pro secrets, jejichž životní cyklus hodnoty je zcela řízen externím poskytovatelem.
Stav synchronizace secretu — indikátor synced_from_external — GetSecretSyncStatus nyní vrací synced_from_external, pokud byl secret úspěšně vytažen z externího poskytovatele. Záložka Secrets zobrazuje tuto informaci jako informační odznak „Synced from KV".
Compliance report — statistiky pokrytí nasazení a synchronizace — PasswordPolicyStats je rozšířen o čítače secrets_with_deployment_target, secrets_with_external_sync a secrets_with_template. Compliance report service je shromažďuje v jediném dalším DB průchodu.
Gateway Task Service — přímé připnutí na gateway ID — GatewayTaskService.CreateTask nyní přijímá volitelný GatewayID, který při nastavení zcela přeskočí vyhledávání v routing service a odešle úlohu přímo na pojmenovanou gateway. Tím jsou podpořeny připnuté post-rotační akce bez nejednoznačnosti routingu.
Čitelnost kódu — Pole struct interních služeb a modelů byla přeformátována pro konzistenci. Parametry resolveRotationResourceIncidentTarget byly zjednodušeny odstraněním redundantních mezilehlých proměnných.

Opravy chyb¶

Dashboard Dismiss — TypeScript zúžení typů — Obslužná rutina dismiss pro položky akciovatelných rotací nyní správně zužuje item.status z 'overdue' | 'failed' | 'running' na serverem přijímaný union 'overdue' | 'failed' před odesláním požadavku, čímž opravuje TypeScript chybu kompilace, která se objevila po přidání 'running' do typového výčtu stavů položky.
Chybějící routes pro Rotation Templates po refaktoru — Pět registrací routes /api/v1/rotation/templates bylo neúmyslně odstraněno při průchodu formátováním kódu. Všech pět routes bylo obnoveno s RBAC middleware (rotation:read / rotation:write).
Swagger path drift pro Rotation Templates — Swagger anotace @Router v handlers_rotation_templates.go nesprávně používaly /rotation-templates místo skutečné gin cesty /rotation/templates. Všech pět anotací bylo opraveno a OpenAPI spec byl vygenerován znovu.
Chybějící audit logging pro operace se Secret Links — Handlery CreateSecretLink a DeleteSecretLink nyní emitují záznamy auditního logu SECRET_LINK_CREATED a SECRET_LINK_DELETED se správným typem zdroje, ID a IP volajícího.

Databázové migrace¶

000167_secret_integration_links_pull_tracking — Přidává sloupce last_pulled_at TIMESTAMPTZ, link_purpose VARCHAR(64) a external_secret_path VARCHAR(512) do secret_integration_links. Obsahuje unikátní constraint uq_sil_secret_integration a partial index pro aktivní linky.
000168_rotation_config_templates — Přidává tabulku rotation_config_templates s kompletními CRUD sloupci (název, popis, org scope, výchozí příznak, interval rotace, lead days, retention days, politika opakování, timeout). Přidává template_id UUID REFERENCES rotation_config_templates do rotation_configs.

Verze 1.0.49¶

Datum vydání: 2026-06-20

Nové funkce¶

Panel akciovatelných rotací na dashboardu — Přehledový dashboard nyní obsahuje vyhrazený panel „Rotation operations", který zobrazuje rotační zdroje po splatnosti nebo ve stavu selhání vyžadující okamžitou pozornost. Každá položka ukazuje druh, projekt a stavový odznak a podporuje jednoklikové odložení (Dismiss) s auditní poznámkou. Zobrazuje se nejvýše pět položek, seřazených podle stáří (po splatnosti) a aktuálnosti (selhání).
Expirující certifikáty na dashboardu — filtr 30 dnů — Sekce „Direct actions" na přehledovém dashboardu nyní filtruje expirující certifikáty na příštích 30 dní, čímž je seznam okamžitě akciovatelný místo zobrazení všech budoucích expirací. Sekce se nyní jmenuje „Expiring certificates (next 30 days)". Endpoint GET /api/v1/dashboard/certificates/expiring přijímá nový volitelný parametr days (1–3650) pro omezení rozsahu; vynechání parametru vrátí všechny budoucí expirace (zpětně kompatibilní).
Entra — staged rotace a dry-run — Rotace Entra přihlašovacích údajů nyní podporuje staged rotaci (staged_rotation_enabled) s konfigurovatelným soak window (soak_window_hours). Obě pole jsou persistována v metadatech rotačního zdroje a správně se přenášejí při GET/PUT cyklu rotační konfigurace. Dry-run cesta validuje workflow rotace vůči živému Entra tenantu bez aplikace jakýchkoli změn.
Entra integrace — Instance ID a verzování protokolu — Entra integrace nyní nesou identifikátor instance a pole verze protokolu, umožňující přesnější cílení a budoucí kompatibilitu ve scénářích s více tenanty a delegovanou orchestrací.
Rotation scheduler — obnova zaseknutých položek — Rotation scheduler nyní detekuje zdroje zaseknuté ve stavu „running" nebo „approval-pending" po překročení konfigurovatelného limitu a resetuje je do znovu spustitelného stavu, čímž zabraňuje tichým nekonečným stálům. Orchestrace obnovení rovněž získala explicitní koordinační logiku pro zdroje procházející oknem obnovení.
Rotace certifikátů — výpočet příštího data splatnosti — Logika výpočtu data splatnosti rotace certifikátů je nyní pokryta dedikovanými unit testy. Příští datum splatnosti je počítáno z efektivní politiky lead days napříč vrstvami certifikátu, šablony a CA účtu, čímž je zajištěno konzistentní chování okna obnovení.

Vylepšení¶

Odolnost načítání dat dashboardu — Načítání dat dashboardu nyní používá Promise.allSettled místo Promise.all. Selhání jednotlivých widgetů (síťová chyba, 401, 404) již nezahazují data ze všech ostatních widgetů. Každé selhání je logováno přes strukturovaný logger pro observabilitu.
RBAC oprávnění pro rotační endpointy — Oprávnění pro čtení a zápis rotačních zdrojů jsou nyní konzistentně aplikována na všech nových dashboard a rotačních endpointech, včetně filtrování archivovaných zdrojů v dotazech servisní vrstvy.
Dashboard — vyloučení archivovaných zdrojů — Dotazy platformního přehledu rotací a akciovatelných rotací nyní explicitně vylučují archivované zdroje, čímž se brání nafukování počtů po splatnosti nebo ve stavu selhání historickými daty.

Opravy chyb¶

Editace Entra rotační konfigurace — regrese zakázaného stavu — Editace existující rotační konfigurace Entra přihlašovacích údajů již nezobrazuje všechna pole jako zakázaná pro ne-primární přihlašovací údaje. GET odpověď nyní vrací rotation_enabled z uložené uživatelské preference (metadata.rotation_enabled) namísto ze scheduler gate (resource.Enabled = RotationEnabled && IsPrimary), která byla vždy false pro ne-primární přihlašovací údaje.
Entra rotační konfigurace — staged pole se neobnovovala při editaci — staged_rotation_enabled a soak_window_hours jsou nyní zahrnuty v metadatech projektoru rotačního zdroje a jsou proto správně obnoveny při otevření existující rotační konfigurace pro editaci.
Entra scope binding — Tenant ID není povinné — Vytvoření Entra scope bindingu již nevyžaduje tenant_id, pokud integrace používá autentizaci managed identity. Backend validace i frontend průvodce byly aktualizovány tak, aby tenant_id bylo pro managed identity flow volitelné.

Infrastruktura¶

Step-CA network policy — Přidáno pravidlo network policy umožňující příchozí provoz na Step-CA na portu 9000 z interního clusteru, čímž se odblokují ACME issuance flow na stagingu routované přes interní Step-CA provisioner.

Verze 1.0.48¶

Datum vydání: 2026-06-16

Nové funkce¶

Domain Control Validation (DCV) pro objednávky externích CA — Poskytovatelé externích CA (DigiCert CertCentral v2, SSLMarket), kteří vyžadují doklad vlastnictví domény před vydáním certifikátu, nyní mají plnou podporu životního cyklu DCV. Nová tabulka certificate_dcv_tokens (migrace 000166) ukládá ověřovací tokeny pro každou doménu. Backend automaticky načítá tokeny po odeslání objednávky, přepne položku ve frontě obnovení do stavu pending_dcv a provádí polling každých 5 minut. Frontend komponenta DCVStatusPanel zobrazuje detaily výzvy pro každou doménu (název/hodnota DNS TXT záznamu, cesta/obsah HTTP souboru nebo e-mail schvalovatele) s tlačítky pro kopírování do schránky, indikátorem průběhu a ručním spuštěním ověření. Nové API endpointy GET /api/v1/renewal-queue/{id}/dcv a POST /api/v1/renewal-queue/{id}/dcv/retry zpřístupňují stav DCV s RBAC (certificate:read / certificate:write).
ADCS čekající na schválení — neblokující DCOM odeslání — Metoda ADCS DCOM již neblokuje goroutinu HTTP handleru smyčkou 5 × 5 s opakovaných pokusů, pokud správce CA ještě neschválil požadavek (stav ADCS 5). Nyní okamžitě vrátí ErrADCSPendingApproval; stávající background job ADCSApprovalPoller zajistí asynchronní načtení certifikátu po schválení.
Možnosti kompatibilního profilu PFX — Export certifikátu do PFX nyní podporuje výběr kompatibilního profilu (legacy / modern), který řídí šifrovací a MAC algoritmy použité v PKCS#12 kontejneru. legacy cílí na OpenSSL 1.x, nástroje Java KeyStore a starší Windows endpointy; modern cílí na OpenSSL 3.x, .NET 6+ a aktuální Go runtime.
Žádost o certifikát — rozšířená pole Subject DN — Modal Žádost o certifikát nyní nabízí volitelná pole Subject DN: Organizace (O), Organizační jednotka (OU), Lokalita (L), Stát/Provincie (ST) a Země (C). Vyplněné hodnoty jsou odeslány jako strukturovaný objekt requested_subject v payload CSR požadavku.
Žádost o certifikát — přepis algoritmu klíče — Pro páry klíčů generované MazeVault mohou operátoři nyní přepsat algoritmus klíče (RSA, ECDSA, Ed25519) a velikost klíče přímo v modalu Žádost o certifikát. Výběr je odeslán jako requested_key_algorithm a requested_key_size v payload CSR.

Vylepšení¶

Redakce logů — zachování původní URL požadavku — Middleware redakce logů nyní uchovává původní RequestURI v Gin kontextu před jakýmkoli přepisováním nebo normalizací cesty. Tím se zajistí, že auditní a strukturované log záznamy odráží URL, kterou klient skutečně odeslal, nikoli artefakt po-zpracování. Regresní test pokrývá kontrakt zachování URL.
Stahování binárních souborů — ArrayBuffer a odložené odvolání URL — Stahování certifikátů a binárních souborů agentů nyní používá typ odpovědi arraybuffer a oddaluje odvolání object URL dokud stahování není spolehlivě doručeno do prohlížeče, čímž se eliminuje race condition na pomalých připojeních, kde odvolání proběhlo dříve než dokončení stahování.

Aktualizace závislostí¶

form-data a hasown — Aktualizovány balíčky form-data a hasown na nejnovější patch vydání, řeší drobná upozornění na kompatibilitu s aktuálními verzemi Node.js runtime.

Verze 1.0.47¶

Datum vydání: 2026-06-14

Nové funkce¶

Sdílené Entra rollout akce a readiness kontroly — Rotace Entra přihlašovacích údajů nyní podporuje seřazené rollout akce nad sdílenou rotační platformou, včetně Azure Key Vault, Kubernetes Secretů, agentem spravovaných runtime souborů, Spring refresh a webhook doručení a recycle IIS app poolu na Windows cílech. Dry-run a preflight kontroly validují stejné runtime cesty ještě před produkčním execution.
Per-certifikátová politika obnovy klíče — Operátoři nyní mohou pro každý certifikát určit, zda obnova vygeneruje nový privátní klíč, nebo pokud to provider a custody cesta dovolí, znovu použije stávající klíčový materiál. Pořadí zpracování rotačních cílů je nově zachováno explicitně v renewal workflow.
Silnější validace autentizační konfigurace Entra integrace — Integration Wizard i backend nyní společně validují interaktivní a background Entra autentizační nastavení, takže už nelze uložit konfiguraci, která by nefungovala pro background sync, dry-run nebo post-rotation execution.

Vylepšení¶

Sjednocený pohled na readiness v Project Rotations — Pohled Project Rotations nyní zobrazuje inline readiness a preflight stav pro Entra přihlašovací údaje, zdroje obnovy certifikátů i deployment zdroje certifikátů, včetně čitelnějšího surfacování stavů manual review required u rollout cílů, které nelze ověřit automaticky.
Sladění rolí a kontraktů pro rotační operace — RBAC migrace a permission kontroly na projektových surface byly sladěny s rozšířenými rotačními a konfiguračními workflow, takže se snižuje počet situací, kdy operátor otevře obrazovku bez oprávnění potřebných k dokončení akce.
Obnova Swaggeru a provozních signálů — Generovaný Swagger nyní odráží rozšířenou slovní zásobu severity stavů a lepší práci s host konfigurací, zatímco kontroly zdraví certifikátů a databáze vracejí přesnější diagnostiku pro rotation readiness a exportní cesty.
Obnovený kontrakt Secret Rotation API — Secret rotation API i generovaný Swagger nyní přesněji popisují explicitní lifecycle create/edit/delete, včetně perzistence post-rotation akcí a čisté reset cesty po odstranění rotace secretu.

Opravy chyb¶

Konzistentní cleanup Entra lifecycle záznamů — Smazání Entra integrace nebo lokálně spravované registrace aplikace nyní ve stejné lifecycle operaci odstraní i související rotační zdroje Entra přihlašovacích údajů. Upgrade migrace 000155 navíc odstraňuje historické osiřelé řádky a repository čtení obranně skrývá zastaralé entra_credential záznamy, které cleanup předcházely.
Výchozí chování rotace certifikátů po importu — Pokud je importovaný certifikát způsobilý pro spravovanou obnovu, MazeVault nyní připraví rotační konfiguraci bez tichého zapnutí automatizace. Počáteční lead days se navíc určují z efektivní politiky certifikátu, šablony a CA účtu místo přepsání modelovým defaultem.
Robustnější validace rolloutu a exportu — Validace kroků s agent_id versus přímým agent_url je přísnější a exporty certifikátů nyní vracejí čitelnější chyby pro PFX a soukromé klíče místo částečně maskovaných selhání.
Mazání a znovuvytvoření secret rotace — Smazání secret rotace nyní odstraní rotační konfiguraci, kanonický secret rotation resource i navázané rotační integrace, aniž by smazalo samotný secret. Po smazání zobrazují secretové status surface stav Rotation not configured a opětovné otevření modalu zůstává v create režimu, dokud operátor explicitně neuloží novou konfiguraci.

Verze 1.0.46¶

Datum vydání: 2026-06-09

Nové funkce¶

Základ pro External CA Order Poller — MazeVault přidal background polling pro externě vydávané objednávky certifikátů, takže asynchronní workflow třetích stran mohou dokončit issuance a propsat změnu do životního cyklu certifikátu bez ručního sledování.

Poznámky¶

Upřesnění release notes — Entra rotation rollout, sjednocení UI rotace certifikátů a související readiness a preflight práce, které byly dříve rozepsané pod v1.0.46, byly dokončeny až po tagu a jsou proto zdokumentovány pod v1.0.47.

Verze 1.0.45¶

Datum vydání: 2026-06-09

Nové funkce¶

Registr rotačních zdrojů a rozšíření platformního vlastnictví — Rotační platforma se rozšiřuje z certifikátové orchestrace na model zdrojů postavený nad registry. Nové control-plane služby zavádějí druhy zdrojů, registry cílů a sdílené vlastnictví plánování rotací, takže budoucí rotace secrets, certifikátů i Entra přihlašovacích údajů budou stát na stejných platformních primitivech.
Discovery policy bundle pro agenty a perzistentní index konfigurací — Agenti nyní dostávají discovery policy bundle generovaný backendem z aktivních konfiguračních šablon. Filesystem discovery ukládá lokální metadata index a znovu používá kešované nálezy konfigurací i certifikátů mezi běhy, aniž by se ztrácela autorita změn politik.
Odesílání výsledků konfigurační discovery — Agenti nyní umí odesílat výsledky discovery konfigurací zpět do backendu včetně klasifikace a metadat rewrite plánu s využitím stávajícího modelu discovery výsledků.
Deduplikace kódů certifikátových šablon a řešení konfliktů — Správa certifikátových šablon na úrovni organizace nyní deduplikuje kódy šablon a blokuje nejednoznačné konflikty. Migrační krok zároveň normalizuje existující duplicity, aby routování šablon a issuance zůstaly deterministické.
Klasifikace systémových certifikátů — Certifikáty nyní nesou příznak is_system pro interní mTLS a identity-management materiál. MazeVault tyto certifikáty může nadále používat interně, aniž by se míchaly do běžného operátorského inventáře.
Integrační skupiny — Projekty nyní podporují pojmenované integrační skupiny mapující logická seskupení na integrační cíle se strukturovanou JSONB konfigurací. Skupiny lze vytvářet, prohlížet, aktualizovat a mazat prostřednictvím nových API endpointů /api/v1/projects/{id}/integration-groups a /api/v1/integration-groups/{id} (migrace 000152).
Reálné Slack notifikace incidentů — Správa incidentů nyní odesílá real-time Slack notifikace prostřednictvím nakonfigurovaného Incoming Webhooku. Při vzniku incidentu u projektu s aktivní Slack integrací platforma odešle typ incidentu a název zdroje do nakonfigurovaného kanálu.
Testy konektivity GCP Secret Manager a Kubernetes — Kontroly zdraví integrace nyní ověřují živé připojení k GCP Secret Manager API (výpis secrets v daném projektu) a dosažitelnost Kubernetes API serveru pomocí in-cluster nebo kubeconfig přihlašovacích údajů, doplňují tak stávající testy providerů.
Operace s klíči HSM — HSM provideři (PKCS#11, AWS CloudHSM, GCP Cloud HSM, Azure Managed HSM) nyní poskytují úplné lifecycle operace s klíči: GetPublicKey (rekonstruuje RSA/EC PKIX DER z hardware), DeleteKey (zničí všechny objekty klíče na zařízení), ListKeys (výpis všech spravovaných key handle) a GetKeyInfo (vrací typ, velikost a příznak exportovatelnosti klíče).
Vault PKI – úplný lifecycle — HashiCorp Vault CA provider nyní implementuje kompletní CA rozhraní: RenewCertificate, GetCertificateStatus (kontrola časového razítka revokace), ListIssuedCertificates (výpis přes PKI list endpoint), GetOrderStatus a CancelOrder (revokuje podkladový certifikát).
ADCS – načtení odloženě vydaného certifikátu — ADCS (WCCE) provider nyní načítá certifikáty vydané CA asynchronně prostřednictvím SOAP Renew požadavku. Dříve nevyřízené certifikáty jsou po dokončení issuance načteny a vráceny ve formátu PEM.
Venafi VaaS – úplný lifecycle — Venafi CA provider nyní implementuje RenewCertificate, GetOrderStatus (načítá stav pick-up z VaaS) a CancelOrder.
Hlášení rate limitů DigiCert — Provider DigiCert nyní dotazuje živé rate limit hlavičky (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) a zpřístupňuje je přes rozhraní GetRateLimits.
Injekce konfigurací s živými hodnotami secretů — Verzování konfigurací nyní při vytváření snapshotu nahrazuje tokeny ${VAULT:<placeholder>} skutečnými hodnotami MazeVault secretů, takže injektované konfigurační soubory obsahují reálné přihlašovací údaje, aniž by byly ukládány do historie verzí konfigurace.

Vylepšení¶

Projektově vázané politiky viditelnosti zdrojů — Azure discovery endpointy nyní aplikují filtrování resource_visibility_policy v kontextu vybraného projektu. Výběr v Integration Wizardu tak odpovídá scope projektu i pro ne-admin operátory.
Auditovatelnost správy konfigurace — Workflow správy konfigurace nyní zaznamenávají auditovatelné aktivity rewrite plánů, takže provozní změny jsou dohledatelné stejně jako ostatní lifecycle události platformy.
Metadata generovaného CSR a custody klíče — Certificate request flow nyní nese metadata o generovaném CSR a custody soukromého klíče dál do dalších lifecycle kroků, takže je zřejmé, zda MazeVault klíč vlastní, znovu používá, nebo musí zachovat externí správu.
Delegovaný krok synchronizace secretu přes agenta — Rotační a execution pipeline nyní mají explicitní krok synchronizace secretu přes agenta, což zlepšuje soulad mezi platformní orchestrací a tím, co agent skutečně aplikuje na cílových systémech.
Navigace certifikátů na vlastnické surface — Odkazy na certifikáty z hlavního dashboardu, projektových rotací i certifikátového inventáře nyní vedou přímo na vlastnickou surface. Projektové certifikáty otevírají detail v projektu, zatímco nezařazený inventář otevírá Discovered Certificates přes lookup podle managed_certificate_id, čímž se nahrazuje duplicitní legacy flow /certificates.
Konzistence dat na Secrets Dashboardu — Záložka Secrets Overview nyní používá sdílené dashboard API, znovu zpřístupňuje drill-in pro chybějící secrets a drží overview počty i dešifrované názvy v souladu s hlavní dashboard datovou vrstvou.
Filtr lookupu objevených certifikátů — Discovery API a generovaná Swagger dokumentace nyní podporují filtrování podle managed_certificate_id, což umožňuje cílené deep linky z certifikátových přehledů na odpovídající discovered certificate záznam.

Opravy chyb¶

Převzetí vlastnictví plánování rotací — Scheduling obnov se přesouvá pod sdílený model platformního vlastníka rotací, aby navazující workflow pracovaly s aktuálním certifikátovým zdrojem místo zastaralých anchorů před obnovou.
Konzistence project contextu v discovery — Integration discovery helpery nyní konzistentně předávají project context, čímž mizí prázdné nebo příliš široké Azure discovery výsledky při zapnutém filtrování viditelnosti zdrojů.
Autentizace Detect Drift — POST /api/v1/secrets/drift/detect se nyní vykonává uvnitř autentizované secrets route group, což opravuje 401 chyby způsobené chybějícím auth kontextem při detekci driftu.
Regrese dashboard drill-in odkazů — Opraveny zastaralé odkazy na certifikáty mířící na odstraněnou globální stránku certifikátů a obnoveny odkazy na chybějící secrets v Secrets Dashboard overview.

Verze 1.0.44¶

Datum vydání: 2026-05-25

Nové funkce¶

Post-akce po rotaci certifikátu — Rotace certifikátů nyní podporuje explicitní řetězení post-rotation akcí včetně webhooků a dalších registrovaných post-processing kroků, takže po úspěšné obnově nebo deploymentu lze spustit navazující refresh a rollout workflow.
Delegovaná obnova a publish kontroly rotace — Orchestrace obnov získala delegované execution cesty, runtime probe validace a publish-gate ochrany, které lépe oddělují readiness validaci od side-effecting deployment práce.
Lifecycle enforcement Archive Centeru — Obnova z archivu a permanentní mazání jsou nyní chápány jako centralizované archive-lifecycle operace s admin-only vynucením v runtime RBAC i při editaci rolí.
Rozšířené pokrytí binárek agentů — Distribuce MazeVault agentů nyní zahrnuje širší ARM64 pokrytí a silnější build validaci pro heterogenní Windows i Linux prostředí.

Vylepšení¶

Sledování key custody u objevených certifikátů — Adoptované discovered certifikáty nyní zachovávají explicitní stav key custody, takže MazeVault tiše nepřebírá vlastnictví privátních klíčů během obnovy nebo deploymentu.
Vyšší robustnost issuance a renewal certifikátů — Flows vydávání certifikátů, zpracování CSR a obnov nyní používají silnější locking, normalizované post-action payloady a jasnější actor attribution napříč cross-project secret operacemi.
Širší pokrytí providerů pro CA účty — Správa CA účtů a EAB přihlašovacích údajů nyní pokrývá více inicializačních cest providerů včetně Smallstep fallback polí používaných při zakládání a validaci účtu.

Opravy chyb¶

Inicializace Smallstep CA účtu — Vytváření Smallstep CA účtu nyní správně fallbackuje na credential pole jako server_url a metadata provisioneru místo selhání ještě před kontaktem s CA.
Sladění kontraktu rotačních akcí — Certificate post-action handling nyní nabízí jen typy akcí podporované certificate rotation executorem, takže se v UI neobjevují neplatné volby a nesoulad názvů kroků.

Verze 1.0.43¶

Datum vydání: 2026-05-11

Nové funkce¶

Podpora Managed Identity pro Azure Key Vault — Integrace Azure Key Vault nyní podporují Managed Identity a Workload Identity jako způsob autentizace vedle Service Principal. Při výběru Azure Key Vault v průvodci integrací se metoda autentizace pro synchronizaci na pozadí automaticky nastaví na managed_identity. Konkrétní klientské ID managed identity nastavte přes AZURE_MANAGED_IDENTITY_CLIENT_ID, nebo proměnnou ponechte prázdnou — platforma identitu rozpozná z prostředí (AZURE_FEDERATED_TOKEN_FILE + AZURE_CLIENT_ID + AZURE_TENANT_ID pro workload identity).
Instalace agenta jako systemd služba — Instalační skript agenta nyní nasazuje MazeVault agenta jako správnou systemd službu. Automaticky se vytvoří dedikovaný systémový uživatel mazevault-agent a adresáře se omezujícími oprávněními (/etc/mazevault, /var/lib/mazevault, /var/log/mazevault) s vlastnictvím a právy 0750. Služba je nakonfigurována s automatickým restartováním při selhání. Stávající nasazení by měla znovu spustit deployment skript pro získání aktualizované service unit.
Endpoint pro stažení binárního souboru agenta — Nový endpoint vázaný na deployment GET /deployments/:id/agent-binary obsluhuje binární soubor agenta pro dané nasazení. UUID deploymentu slouží jako autentizační token (náhodný 128-bitový identifikátor, který nelze uhodnout), shodně s endpointy /script a /config. Starší pravidla přepisu pro stahování agenta v reverzní proxy byla odstraněna.
Podpora více endpointů Redis — Správa Redis připojení nyní podporuje konfiguraci více adres endpointů pro nasazení s vysokou dostupností a záložním přepínáním. Primární endpoint se konfiguruje přes REDIS_URL, záložní adresy přes REDIS_FALLBACK_URLS (oddělené čárkou, středníkem nebo novým řádkem). Klient automaticky přechází na další dostupný endpoint při výpadku, a pokud jsou nedostupné všechny Redis endpointy, přepne se na in-memory fallback.
Politika složitosti hesel v nastavení organizace — Nastavení organizace nyní obsahuje vyhrazený editor Politiky složitosti hesel. Pravidla jsou vynucována při změně hesla (minimální délka, požadavky na třídy znaků, hloubka historie). Při upgradu jsou organizace automaticky migrovány ze zastaralého pole secret_complexity_policy.

Vylepšení¶

Historie rotace Entra přihlašovacích údajů — Operace rotace Entra ID přihlašovacích údajů nyní vytvářejí trvalý záznam historie rotace pro každou událost. Historie zachycuje typ rotace, staré a nové identifikátory klíčů, workflow a execution ID, průběh po krocích, finální stav, případné chybové detaily a trvání. Umožňuje plnou sledovatelnost životního cyklu rotace Entra přihlašovacích údajů.
Sladění RBAC oprávnění — Oprávnění rolí aktualizována dle dohodnuté produktové politiky:
- secret_manager — přidáno keytab:read a config:read (stránky Správa KeyTab a Správa konfigurace jsou nyní přístupné)
- certificate_manager — přidáno config:read (stránka Správa konfigurace je nyní přístupná)
- auditor — odebráno keytab:read (Správa KeyTab již není viditelná pro auditní role; pro auditní přístup ke KeyTab přiřaďte explicitně oprávnění keytab:read)
Rozšíření typů referencí admin přihlašovacích údajů — Admin přihlašovací údaje k databázi nyní podporují dva nové typy referencí: mazevault (přihlašovací údaje uložené jako MazeVault spravované tajemství) a external (obecné externí reference). Úplná sada podporovaných typů: internal, mazevault, external, keyvault, aws_sm.
Asynchronní seedování synchronizace tajemství s přehledem stavu — Operace seedování synchronizace nyní běží asynchronně a ihned vrací odkaz na průběh s detailním přehledem stavu (tajemství vytvořena, aktualizována, přeskočena, selhala). Zablokované seed incidenty jsou nyní zobrazeny na stránce Řešení konfliktů.
Vydávání certifikátů propojeno s agentem — Certifikáty vydané registrovanému agentovi jsou nyní při vydání propojeny se záznamem vydávajícího agenta, čímž je životní cyklus certifikátu propojen s agentem v dashboardu a rotační orchestraci.
Bezpečnostní vylepšení — obsluha bootstrap a KeyTab — Handlery pro aktualizaci a mazání KeyTab nyní vynucují kontrolu vlastnictví organizace (ochrana proti IDOR): přístup ke KeyTab patřícímu jiné organizaci vrátí 404. Endpoint pro změnu hesla při bootstrapu je uzamčen po dokončení prvotního bootstrapu a odmítá další volání s kódem 403 Forbidden. Do CI pipeline byl přidán DAST (Dynamic Application Security Testing) workflow.
Aktualizace kontaktu pro obnovu licence — Kontaktní e-mail pro obnovu licence je nyní info@mazevault.com ve všech notifikačních bannerech a modalech exspirace.

Opravy chyb¶

SSO Provider Modal: zachování ID poskytovatele při uložení — Opravena chyba, při níž uložení stávající konfigurace SSO poskytovatele způsobilo ztrátu ID poskytovatele, což vedlo k vytváření duplicitních poskytovatelů při dalším uložení.
Zpětné doplnění politiky složitosti hesel — Organizace, které měly nakonfigurovanou politiku složitosti tajemství přes starší pole secret_complexity_policy, byly chybně vyhodnoceny jako nemající žádnou politiku hesel, což způsobovalo falešná selhání kontrol souladu s PCI-DSS 8.3. Politika je nyní při upgradu automaticky propagována do vyhrazeného pole politiky složitosti hesel. Organizace bez jakékoliv nastavené politiky navíc při upgradu obdrží bezpečnou výchozí politiku (minimálně 16 znaků, všechny třídy znaků povinné, historie 10 hesel, rotace každých 30 dní).

Verze 1.0.42¶

Datum vydání: 2026-05-11

Nové funkce¶

Metadata certifikátů — Certifikáty nyní podporují tři uživatelsky editovatelné pole metadat dostupná z detailu certifikátu a přes PUT /api/v1/certificates/:id:
- Tagy — Volně zadávatelné textové štítky pro seskupování a filtrování certifikátů. Tagy nastavené při importu jsou nyní uloženy a zůstávají editovatelné po importu. Odešlete prázdné pole pro smazání všech tagů.
- URL dokumentace — Volitelný odkaz (http/https) na externí dokumentaci, runbooky nebo záznamy CMDB pro certifikát. Maximálně 500 znaků.
- Poznámky — Krátká volně editovatelná anotace (maximálně 256 znaků). Odešlete prázdný řetězec pro smazání poznámky.
- Všechny změny metadatových polí jsou zaznamenány do auditního logu.

Vylepšení¶

Vynucení kanonizace prostředí při vytváření úkolů — Vytváření gateway úkolů nyní vynucuje kanonizaci slugů prostředí. Všechny gateway úkoly jsou ukládány s malými písmeny slugů prostředí bez ohledu na velikost písmen volajícího, navazujíc na kanonizační infrastrukturu zavedenou ve v1.0.41. Proměnná MAZEVAULT_ENV_CANONICAL_ENFORCE (nastavením na true se přejde do fail-closed režimu pro nekanonické vstupy) platí pro vytváření úkolů od tohoto vydání.

Verze 1.0.41¶

Datum vydání: 2026-04-26

Vylepšení¶

Synchronizace dokumentace — Komplexní aktualizace dokumentace pro soulad s kódovou základnou v1.0.41. Reference proměnných prostředí rozšířena o pět nových sekcí: Registrace licence/organizace, Režim Orchestrátora, ACME DNS-01, Správa KeyTab a Proxy binárních souborů agenta. Všechny stávající sekce doplněny o dosud chybějící proměnné.
Opraven název proměnné Office 365 — Opraven nesprávný název proměnné O365_ENABLED → O365_EMAIL_ENABLED v celé dokumentaci. Zdokumentována kompletní konfigurace autentizace Office 365 (metody: client secret, certifikát a managed identity).
Reference API pro KeyTab — Zveřejněna kompletní dokumentace API pro všech 14 endpointů správy KeyTab. Viz API pro KeyTab.
Reference API pro reporty — Zveřejněna kompletní dokumentace API pro týdenní reporty exspirace. Viz API pro reporty.
Synchronizace verze platformy — Všechny stránky dokumentace aktualizovány tak, aby odrážely aktuální verzi platformy.

Verze 1.0.40¶

Datum vydání: 2026-04-25

Nové funkce¶

Vynucení nonce OIDC — Nový příznak MAZEVAULT_ENFORCE_OIDC_NONCE povoluje přísné ověření nonce v OIDC tokenech. Při nastavení na true jsou tokeny bez platného nároku nonce odmítnuty, což chrání před útoky opakovaným přehráním tokenu. Doporučeno pro všechna produkční prostředí.
Řízení trust store agenta — Nové proměnné prostředí MAZEVAULT_AGENT_INSTALL_CHAIN_TO_TRUSTSTORE a MAZEVAULT_AGENT_TRUST_STORE_PATH řídí, zda agent MazeVault nainstaluje interní řetězec CA do systémového úložiště důvěryhodných certifikátů a umožňují přepsat výchozí cestu trust store na Linuxu.

Vylepšení¶

Stav synchronizace cílů rotace certifikátů — GET /api/v1/certificates/:id/targets/:targetId/status nyní vrací úplné detaily výsledků každého kroku, což usnadňuje diagnostiku neúspěšných synchronizací cílů.
Stabilita registrace gateway — Vylepšená logika opakování pro výměnu bootstrap tokenů snižuje počet neúspěšných registrací způsobených přechodnými síťovými problémy při prvním nastavení gateway.
Validace URL OCSP — Proměnná OCSP_URL nyní ověřuje formát URL při spuštění, aby se zabránilo tichému selhávání OCSP v důsledku špatné konfigurace.

Opravy chyb¶

Opravená rezoluce AGENT_VERSION=latest, aby vždy načítala nejvyšší označenou verzi namísto nejnovějšího commitu.
Opraveno překrývání zobrazení v modalu importu certifikátů v režimu Orchestrátora při současné viditelnosti sekcí keytab i soukromého klíče.

Verze 1.0.39¶

Datum vydání: 2026-04-22

Nové funkce¶

Řízení distribuce binárních souborů agenta — Nové konfigurační proměnné umožňují podrobné řízení distribuce aktualizací agenta. AGENT_ROLLOUT_PERCENTAGE omezuje, které procento agentů dostane notifikaci o aktualizaci (0–100), což umožňuje postávkové zavedení. AGENT_MAX_CONCURRENT_DOWNLOADS omezuje paralelní stahování binárních souborů.
Proxy binárních souborů agenta — MazeVault nyní může zprostředkovávat stahování binárních souborů agenta z privátního repozitáře GitHub, čímž odpadá požadavek na přímý přístup hostů agenta k veřejnému GitHub Releases. Konfigurujte přes AGENT_BINARY_GITHUB_TOKEN, AGENT_BINARY_CACHE_DIR, AGENT_DOWNLOAD_BASE_URL a AGENT_VERSION.
Semenáření prostředí primárního backendu — Nová proměnná MAZEVAULT_PRIMARY_ENVIRONMENTS před-nasévá seznam prostředí obsluhovaných přímo primárním backendem při prvním spuštění, což zjednodušuje počáteční konfiguraci nasazení s více prostředími.

Vylepšení¶

Obnovování dashboardu KeyTab — Opraven graf souladu šifer, který se neaktualizoval po importu keytabu se zastaralými šiframi.
Spolehlivé vícekanálové doručení týdenního reportu — Opravena podmínka plánovače, která mohla tiše vynechat jeden doručovací kanál při současném povolení více kanálů.

Opravy chyb¶

Opravena chyba, kdy časové razítko heartbeatu gateway nebylo správně aktualizováno po obnovení ze síťové partice.

Verze 1.0.38¶

Datum vydání: 2026-04-19

Nové funkce¶

Správa KeyTab — kompletní životní cyklus Kerberos — Enterprise správa Kerberos KeyTab souborů s kompletní podporou životního cyklu. Import, discovery a správa keytab souborů napříč infrastrukturou. Klíčové schopnosti:
- Import a parsování — Import MIT Kerberos v2 keytab binárních souborů s automatickou extrakcí principálů, realmů, verzí klíčů (KVNO) a šifrovacích typů. Podporuje nahrání v base64 kódování.
- Discovery agentem — Agenti automaticky objevují .keytab soubory na spravovaných hostech, hlásí cestu k souboru, oprávnění, vlastníka a otisk šifrovacího typu. Objevené keytaby lze importovat do spravovaného inventáře jedním kliknutím.
- Vynucování šifrovacích politik — Definujte šifrovací politiky na úrovni organizace s povolenými a zastaralými šifrovacími typy Kerberos. Tři režimy vynucení: audit (pouze reportování), warn (povolit s varováním), block (zakázat neshody). Výchozí politika blokuje starší šifry (DES, RC4-HMAC) a povoluje moderní AES a Camellia.
- Historie verzí — Všechny aktualizace keytabů vytvářejí neměnitelné záznamy verzí se sledováním důvodu změny pro plný auditní soulad.
- Dashboard a analytika — Vyhrazený dashboard KeyTab zobrazující celkový/aktivní/exspirovaný počet, rozpad souladu s šiframi (vyhovující/varování/kritický), prognózy exspirace a distribuci typů šifer.
- Podpora režimu Orchestrátora — V režimu Orchestrátora se binární data keytab odesílají do externího poskytovatele; lokálně se ukládají pouze metadata.
Týdenní report exspirací — Automatické týdenní reporty zobrazující certifikáty a secrets exspirující do 60 dnů, doručované na více kanálů současně:
- Email — HTML formátovaný report na konfigurovaný seznam příjemců
- Slack / Microsoft Teams — Notifikace přes webhook se souhrnem exspirací
- JIRA — Automatické vytvoření úkolu s detaily exspirace pro sledování
- Generický webhook — HTTP POST s kompletním payloadem reportu pro vlastní integrace
- Reporty lze před odesláním zobrazit jako náhled a spustit ručně na vyžádání.
Registrace lokální gateway — Primární backend se nyní může zaregistrovat jako lokální gateway, což umožňuje jednotné UI správy gateway pro lokální i vzdálené gateway. Unikátní omezení zajišťuje pouze jednu lokální gateway na nasazení.

Vylepšení¶

Podpora více prostředí na gateway — Gateway nyní mohou obsluhovat více prostředí současně, čímž se odstraňuje předchozí omezení jedna-gateway-na-prostředí.
RBAC oprávnění pro reporty — Nová oprávnění report:read a report:write poskytují jemné řízení přístupu k reportovacímu systému. Všechny standardní role (User, Certificate Manager, Secret Manager, Auditor) získávají report:read; Admin a Project Admin navíc získávají report:write.
RBAC oprávnění pro KeyTab — Nová oprávnění keytab:read, keytab:write, keytab:delete a keytab:admin řídí přístup ke správě keytabů. Standardní uživatelé a auditoři získávají přístup pro čtení; operátoři a org admini získávají zápis a mazání; org admini navíc získávají admin přístup pro správu politik.

Opravy chyb¶

Čistění pravidel synchronizace Entra — Odstraněna osiřelá sync pravidla ponechaná smazanými integracemi a vyčištěna duplicitní sync pravidla pro typ poskytovatele entra_id (nyní řešeno dedikovaným Entra Sync Schedulerem). Opravuje opakující se chyby „sync failed for rule" v produkčních prostředích.

Verze 1.0.37¶

Datum vydání: 2026-04-16

Vylepšení¶

Šifrování payloadu úloh gateway — Citlivé payloady úloh vyměňované mezi primárním backendem a gateway jsou nyní šifrovány v klidu v databázi. Příznak payload_encrypted na úlohách gateway zajišťuje, že JSONB payloady obsahující přihlašovací údaje a soukromé klíče jsou chráněny i v případě kompromitace přístupu k databázi.
Exponenciální backoff fronty zápisů — Fronta zápisů pro více datových center nyní sleduje časové razítko každého pokusu o opakování, což umožňuje správný výpočet exponenciálního backoff pro neúspěšné synchronizační operace. Zlepšuje spolehlivost a snižuje zbytečnou zátěž vzdálených gateway během výpadků konektivity.

Bezpečnostní aktualizace¶

Šifrování payloadu gateway v klidu — Výsledky úloh a payloady ve frontě úloh gateway jsou nyní šifrovány před uložením do databáze, čímž se uzavírá potenciální vektor expozice dat v nasazeních s více datovými centry.

Verze 1.0.36¶

Datum vydání: 2026-04-15

Nové funkce¶

Databázové schéma KeyTab — Nové databázové tabulky pro správu keytab: keytabs (šifrované úložiště keytab se sledováním souladu šifer), keytab_versions (neměnitelná historie verzí), keytab_cipher_policies (vynucování šifer na úrovni organizace) a discovered_keytabs (výsledky discovery agentů s detekcí zastaralých záznamů).
RBAC oprávnění KeyTab — Nová sada oprávnění (keytab:read, keytab:write, keytab:delete, keytab:admin) přiřazená příslušným systémovým rolím pro správu životního cyklu keytab.

Vylepšení¶

Vylepšení API tokenů gateway — Vylepšená autentizace gateway s dedikovanými API tokeny a podporou bootstrapového provisioningu.
Discovery KeyTab agentem — Agenti nyní mohou objevovat Kerberos keytab soubory na spravovaných hostech a hlásit zjištění včetně cesty k souboru, oprávnění, vlastníka, typů šifrování a SHA-256 otisku.

Verze 1.0.35¶

Datum vydání: 2026-04-14

Opravy chyb¶

PEM Import — Zachování soukromého klíče — Opravena kritická chyba, kdy import PEM souboru obsahujícího řetěz certifikátů a soukromý klíč tiše zahodil soukromý klíč. Systém správně detekoval klíč při náhledu souboru, ale ztratil ho během vlastního importu, což způsobovalo selhání následných exportů do PFX/JKS. Parser PEM bundlů nyní správně extrahuje PKCS#8, RSA a EC soukromé klíče.
Import certifikátu — Název projektu v chybových zprávách — Při importu certifikátu, který již existuje, chybová zpráva nyní obsahuje název projektu, kde se duplikát nachází (např. „certifikát již existuje … project=MůjProjekt"), což usnadňuje identifikaci konfliktů.

Vylepšení¶

Viditelnost soukromého klíče v UI — Certifikáty nyní zobrazují stav soukromého klíče ve všech pohledech:
- Seznamy certifikátů zobrazují zelenou ikonu štítu, když je uložen soukromý klíč.
- Dashboard certifikátů zobrazuje zelenou ikonu klíče u certifikátů se soukromým klíčem.
- Detail certifikátu zobrazuje chip indikující, zda je klíč uložen lokálně, externě, nebo není k dispozici.

Verze 1.0.34¶

Datum vydání: 2026-04-10

Nové funkce¶

Discovery skupin Identity Provideru — Nový API endpoint GET /identity-providers/{id}/groups načítá skupiny přímo z nakonfigurovaného poskytovatele identity (Entra ID přes Microsoft Graph, LDAP přes adresářové vyhledávání). Podporuje filtrování pomocí vyhledávání podle názvu skupiny pro snadné mapování rolí.
Test pokrytí Identity Provideru — Přidáno komplexní pokrytí unit testy pro CRUD operace poskytovatele identity, test-connection flow a endpointy pro discovery skupin.

Vylepšení¶

JKS Export — Čistá Go implementace — Nahrazena externí závislost na keytool (JDK) nativní Go implementací pomocí keystore-go/v4. Export JKS nyní funguje v jakémkoliv prostředí bez nutnosti Java runtime, obsahuje kompletní řetěz certifikátů a má komplexní pokrytí testy.
Autentizace Gateway API tokenem — Nová tabulka gateway_api_tokens a middleware pro autentizaci gateway-to-backend API. Gateway se nyní mohou autentizovat pomocí dedikovaných API tokenů s automatickým provisioningem při bootstrapu.
Fronta zápisů Gateway — Přidána tabulka gateway_write_queue pro bufferování zápisových operací z gateway, což umožňuje spolehlivou synchronizaci dat v nasazeních s více datovými centry.
Posílení bootstrapu Gateway — Vylepšený bootstrap flow gateway s rozšířenou validací, kontrolami konektivity Azure SQL a spolehlivější počáteční registrací.
Terraform pro Azure testovací prostředí — Nová konfigurace Terraformu pro automatizovaný provisioning Azure testovacího prostředí, včetně Entra ID enterprise aplikací, Key Vaultů a Azure SQL.

Bezpečnostní aktualizace¶

Middleware autentizace Gateway — Nový dedikovaný middleware validuje API tokeny gateway se správnými kontrolami scope a propagací kontextu požadavku.

Verze 1.0.33¶

Datum vydání: 2026-04-09

Nové funkce¶

Endpointy pro kontrolu Azure oprávnění — Přidány nové API endpointy pro validaci přístupů a viditelnosti zdrojů v Azure:
POST /api/v1/admin/azure/mi-permissions-check
GET /api/v1/azure/user-permissions-summary
GET /api/v1/azure/subscriptions/{subscriptionId}/sql-servers
Validace oprávnění Managed Identity — Nový kontrolní tok Managed Identity ověřuje přístup ke konfigurovaným Azure integracím a vrací stav po jednotlivých integracích.
Souhrn uživatelských oprávnění — Přidán konsolidovaný přehled Azure zdrojů viditelných pro přihlášeného uživatele na úrovni subscription, včetně Key Vault a SQL server discovery.

Vylepšení¶

RBAC integrace pro Azure permission checks — Endpointy kontroly Azure oprávnění jsou nyní chráněné MazeVault RBAC pomocí guardů integration:read a integration:write.
Pokrytí Swagger schémat — Definice OpenAPI nyní obsahuje response modely pro Azure permission check (MIPermissionsCheckResponse, MICheckResult) pro přesnější generování API klientů.

Bezpečnostní aktualizace¶

Sjednocení oprávnění rolí — Migrace 000109_add_audit_settings_permissions přidává oprávnění audit:read a project:write rolím certificate_manager a secret_manager pro konzistentní chování řízení přístupu.

Verze 1.0.32¶

Datum vydání: 2026-04-08

Nové funkce¶

Integrace Azure Managed HSM — Plná podpora pro ukládání a manipulaci klíčů v Azure Managed HSM s automatickými aktualizacemi certifikátů a rotací klíčů. Všechny operace se soukromými klíči se provádějí v HSM s metadaty vrácenými do databáze.
Zásady hesel na úrovni organizace — Definujte pravidla pro vynucování hesel (minimální délka, složitost, doba platnosti) pro všechny uživatele organizace. Pravidla se vynucují při vytvoření a změně hesla s kompatibilitou pro staré integrace.

Vylepšení¶

Výkon synchronizace CRDT — Optimalizované řešení konfliktů pro datasety >100k záznamů, zlepšení rychlosti o 40% na setupech s více datovými centry.
Rozšířené auditní protokoly — Komplexní zaznamenávání všech operací týkajících se hesel, certifikátů a administrativních akcí.

Opravy chyb¶

Opraveno časování zneplatnění cache v clusterových nasazeních.
Vyřešena selhání synchronizace s velkými CSR transakcemi.

Verze 1.0.31¶

Datum vydání: 2026-04-07

Nové funkce¶

Režim Orchestrátora — Uchovávání klíčů externě — MazeVault nyní může běžet v režimu, kde jsou všechny soukromé klíče a tajemství ukládány výhradně v externích úschovnách klíčů (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault). Místní databáze obsahuje pouze metadata.
Sledování souladu s licencí — Dashboard zobrazuje stav licence v reálném čase, včetně použitých licencí, nadcházejících vypršení a stavů varování.

Vylepšení¶

Migrace ze standardního režimu do režimu Orchestrátora — Nové příkazy CLI pro bezpečnou migraci existujících systémů v standardním režimu do režimu Orchestrátora.
UI režimu Orchestrátora — Přepínač v průvodci onboardingem a v nastavení organizace.

Opravy chyb¶

Opraveno selektivní kopírování certifikátů v režimu Orchestrátora.

Verze 1.0.30¶

Datum vydání: 2026-04-07

Nové funkce¶

ACME Server — plná implementace RFC 8555 — MazeVault nyní funguje jako plně kompatibilní ACME certifikační autorita. Jakýkoliv standardní ACME klient (cert-manager, Certbot, acme.sh, Kubernetes) může přímo od MazeVault získávat a obnovovat certifikáty bez manuálního zásahu. Podporované typy výzev: HTTP-01, DNS-01, TLS-ALPN-01.
External Account Binding (EAB) — Registrace ACME účtů lze omezit pouze na autorizované klienty pomocí předsdílených EAB přihlašovacích údajů (HMAC). Zabraňuje neoprávněnému vydávání certifikátů neznámými ACME klienty.
Dashboard synchronizace — Nová sekce dashboardu zobrazuje stav synchronizace v reálném čase: přehled konfigurací, aktivní konflikty a selhání synchronizace s návodem pro řešení jednotlivých položek.
Oprávnění sync:read — Nové oprávnění sync:read umožňuje členům projektů, auditorům a držitelům rolí přístup k stavovým endpointům synchronizace bez potřeby zvýšených oprávnění.

Vylepšení¶

Posílení ACME Authorization Nonce — Vyhrazená tabulka nonce (acme_server_nonces) s TTL exspirací zajišťuje přísnou ochranu replay-nonce dle RFC 8555 §6.5.
Indexování ACME challenge tokenů — Challenge tokeny nyní využívají vyhrazený indexovaný sloupec pro validaci s O(1) dotazy místo skenování JSON, čímž se zvyšuje propustnost při vysokém objemu ACME požadavků.
RBAC — sjednocení oprávnění synchronizace — Role project_admin, certificate_manager, secret_manager, user a auditor nyní zahrnují sync:read pro konzistentní přístup ke sync dashboard endpointům.

Opravy chyb¶

Opravena race condition v přechodech stavu ACME order při souběžných finalize požadavcích.
Vyřešen problém s pořadím vytváření ACME authz tabulek (idempotentnost migrace).

Verze 1.0.29¶

Datum vydání: 2026-04-06

Nové funkce¶

Rozhraní pro správu konfigurace — Nové záložkové UI pro správu životního cyklu konfiguračních souborů: discovery YAML/JSON/INI souborů napříč prostředími, přípravná oblast pro koncepty a propagace konfigurací do produkce. Poskytuje přehled o počtu discoveredvs. spravovaných konfigurací.
Polymorfní konfigurace rotace certifikátů — Záznamy rotace nyní podporují jak rotaci secretů, tak certifikátů v unified modelu. Pole config_type rozlišuje oba typy, čímž eliminuje samostatné tabulky workflow.
Sledování zdroje nastavení obnovení — Každý certifikát nyní zaznamenává, zda jeho nastavení obnovení pochází z projektové šablony (template) nebo bylo nastaveno ručně (manual), což poskytuje jasnou auditní stopu pro chování rotace.

Vylepšení¶

Organizační izolace žádostí o certifikáty — Žádosti o podpis certifikátů (CSR) jsou nyní vázány na organizaci původce. Pole organization_id je zpětně doplněno z projektových asociací, čímž se zabraňuje úniku CSR dat mezi organizacemi.
Databázová schémata ACME serveru — Databázové schéma pro ACME serverový protokol (autorizační objekty a nonce tabulky) bylo připraveno pro vydání ACME serveru v 1.0.30.
Čistění workflow rotace — Odstraněny zastaralé tabulky rotation_workflows a rotation_step_executions nahrazené unified modelem spuštění rotace.

Opravy chyb¶

Opraveno přejmenování sloupce rotation_configs.next_rotation na next_rotation_at — dotazy plánovače nyní používají správný název sloupce.
Vyřešeno omezení cizího klíče na rotation_executions.config_id, které bránilo polymorfním odkazům na konfiguraci rotace.

Verze 1.0.28¶

Datum vydání: 2026-04-05

Nové funkce¶

Zásady pojmenování secretů — Definujte celoorganizační konvence pojmenování secretů pomocí regex pravidel se třemi úrovněmi vynucení: block (zakáže vytvoření), warn (povolí s varováním) a disabled (informativní). Zásady jsou spravovány jako konfigurační šablony a validovány v reálném čase při vytváření secretu.
Dashboard souladu s pojmenováním — Nová záložka v Secrets Dashboardu zobrazuje heat mapu porušení zásad, míru souladu na úrovni jednotlivých pravidel a automaticky generované návrhy pravidel na základě existujících vzorců pojmenování secretů.
Framework konzistence — Vytvořte skupiny konzistence pro ověření existence specifikovaných secretů ve všech požadovaných prostředích. Endpoint POST /projects/{id}/consistency/groups a záložka dashboardu povrchně zobrazují chybějící hodnoty a mezery v prostředích s podporou resolve-warning pro dokumentované výjimky.
Výchozí nastavení zabezpečení databáze — Organizace nyní mohou konfigurovat TLS/šifrování pro databázové integrace na úrovni prostředí. Produkční prostředí výchozím nastavením vyžaduje přísné TLS (verify-full, encrypt, TCPS); neprodukční prostředí využívají permisivní výchozí nastavení. Podporovatelé: Oracle, MSSQL, PostgreSQL, MongoDB, MySQL.
Vylepšené sdílené secrety — Sdílené secrety nyní podporují volitelnou ochranu heslem (bcrypt), recipient_email pro sledování záměru, automatické označení typu obsahu (secret nebo certificate) a atribuci zdroje rotace (source_type, source_id) pro automatizovanou distribuci po rotaci.

Bezpečnostní aktualizace¶

Oprávnění RBAC pro konzistenci — Nová oprávnění consistency:read a consistency:write řídí přístup ke skupinám konzistence a řešení varování. Přiřazena rolím project_admin, certificate_manager, secret_manager, user a auditor.
Zpřesnění role auditora — Role auditor již nemá přístup k deployment dashboardu ani obecným dashboard pohledům, čímž se role striktně zaměřuje na audit logy, správu uživatelů, stav gateway a agentů — redukuje útočnou plochu účtů pouze pro čtení.

Opravy chyb¶

Opraveno ukládání zásad pojmenování secretů: zásady jsou nyní persistovány v config_management_templates místo zastaralého JSONB sloupce organizations.secret_complexity_policy.

Verze 1.0.27¶

Datum vydání: 2026-04-04

Nové funkce¶

Nové role: Certificate Manager a Secret Manager — Dvě nové specializované role poskytují jemné řízení přístupu bez udělení viditelnosti napříč doménami:
certificate_manager — Plná správa životního cyklu certifikátů, CA účtů, šablon, discovery a deploymení. Bez přístupu k secretům.
secret_manager — Plná správa životního cyklu secretů, rotace, deploymení a integrací. Bez přístupu k certifikátům.
Vzor autorizačního kódu SSO — Přístupové tokeny se již nepředávají přes URL parametry při SSO callbacku. Callback nyní doručuje krátkodobý kód (sso_code, 60sekundová TTL), který frontend vymění za tokeny prostřednictvím POST /auth/sso/exchange. Eliminuje se tím expozice tokenů v historii prohlížeče, serverových přístupových lozích a hlavičkách Referer. Platí pro poskytovatele SSO: Entra ID, GitHub a GitLab.
Konsolidace mapování skupin Entra — Mapování skupin Entra ID na role jsou nyní uložena v unified tabulce group_role_mappings se sloupcem source (local nebo entra). To umožňuje konzistentní správu skupin z lokálních LDAP skupin i cloudových skupin Entra ID z jednoho rozhraní.

Bezpečnostní aktualizace¶

Validace OIDC Nonce — OAuth2 stav nyní nese serverem generovaný nonce validovaný při výměně tokenu. Zabraňuje CSRF/únosu tokenu prostřednictvím cross-site OAuth substituce stavu.
Odebrání zastaralých rolí — Starší role (operator, developer, org_admin, secret_editor, secret_viewer, certificate_admin, system_admin) byly odebrány. Stávající uživatelé s těmito rolemi byli automaticky migrováni: operator → project_admin, developer → user. Integrace používající zastaralé názvy rolí v API voláních musí být aktualizovány.
Integrita dat uživatelských rolí — Opravena korupce primárního klíče s nulovou UUID v tabulce user_roles způsobená chybějícím hookem BeforeCreate. Byl přidán kompozitní unikátní index k zabránění duplicitním přiřazením rolí. Postižené záznamy byly zpracovány deduplikací během migrace.
Index soft-delete emailu uživatele — Omezení unikátnosti emailu je nyní partial index (WHERE deleted_at IS NULL). Soft-smazaní uživatelé již neblokují vytvoření nového účtu ani SSO registraci se stejnou emailovou adresou.

Opravy chyb¶

Opravena duplikace mapování skupin Entra po opětovném přihlášení SSO.
Vyřešena selhání přiřazení rolí pro uživatele vytvořené prostřednictvím LDAP group sync.

Verze 1.0.26¶

Datum vydání: 2026-04-03

Nové funkce¶

Vylepšení importu PFX/PKCS#12 — Vylepšený import PFX certifikátů s lepším parsováním a validací
Opravy šablon certifikátů — Vyřešeny problémy s konfigurací šablon ovlivňující workflow enrollmentu certifikátů
Úpravy mapování rolí — Aktualizovaná logika mapování skupin na role pro lepší SSO integraci
Rozšíření auditních logů — Rozšířené auditní logování s dalšími typy událostí a vylepšenou sledovatelností

Bezpečnostní aktualizace¶

Komplexní remediace zranitelností — Vyřešeno 18 z 24 identifikovaných zranitelností napříč všemi komponentami platformy prostřednictvím systematického skenování a aktualizace závislostí
Oprava obejití SAML podpisu (KRITICKÉ) — Opravena kritická zranitelnost obejití XML podpisu v SAML SSO autentizačním toku (goxmldsig v1.3.0 → v1.6.0)
Oprava HTTP/2 CONTINUATION flood (KRITICKÉ) — Vyřešena aktivně zneužitelná HTTP/2 denial-of-service zranitelnost v Kubernetes Operátoru (golang.org/x/net v0.19.0 → v0.52.0)
Oprava obejití autorizace gRPC — Opraveno obejití autorizace gRPC přes chybějící lomítko v cestě (google.golang.org/grpc → v1.80.0)
Opravy JOSE/JWE Denial-of-Service — Vyřešeny 3 samostatné DoS zranitelnosti v JSON Web Encryption (go-jose/v3 v3.0.0 → v3.0.4)
Kritická oprava Node.js SDK — Eliminováno 8 kritických Handlebars.js advisories včetně JavaScript injection a prototype pollution
Posílení bezpečnosti CI/CD — Připnutí Trivy security scanneru na konkrétní verzi (ochrana supply chain), povolení bezpečnostního skenování na všech CI událostech

Vylepšení¶

Přepracování Kubernetes Operátoru — Velká aktualizace závislostí na controller-runtime v0.22.5 a k8s.io/* v0.34.3 s vylepšením kvality kódu včetně extrahovaných reconciliačních metod, konfigurovatelných intervalů obnovení, správné propagace watch a strukturovaného logování
Oprava Terraform Provideru — Opravena chyba kompilace a aktualizovány všechny závislosti na nejnovější stabilní verze (terraform-plugin-framework v1.19.0, grpc v1.80.0)
Vylepšení Go SDK — Přidáno pole Environment do modelu Project pro vylepšenou správu projektů
Posílení Docker obrazů — Připnutí základního obrazu OCSP Responderu na alpine:3.21 (reprodukovatelné buildy), přepnutí Frontendu na npm ci pro deterministickou instalaci závislostí
Sjednocení závislostí — Sjednocení golang.org/x/crypto, golang.org/x/net a dalších standardních knihoven napříč všemi 7 Go moduly na nejnovější stabilní verze

Verze 1.0.25¶

Datum vydání: 2026-04-01

Nové funkce¶

Přepracování Swagger API dokumentace — Kompletní regenerace Swagger/OpenAPI dokumentace s úplným pokrytím endpointů, vylepšenými definicemi schémat a přesnými příklady požadavků/odpovědí
Konfigurace prostředí Entra ID SSO — Nové proměnné prostředí pro konfiguraci Entra ID SSO a Azure Managed Identity v .env.example pro zjednodušené nasazení

Vylepšení¶

Konfigurace LDAP a OAuth poskytovatele — Vylepšené nastavení SSO poskytovatele s lepším zpracováním LDAP bind DN a konfigurací OAuth2 flow
Endpoint stavu emailů — Nový endpoint GET /api/v1/system/email-status pro monitorování stavu doručení emailových notifikací
Handlery rotace certifikátů — Nové API handlery pro provádění rotace certifikátů a sledování stavu
Vylepšení integrace agentů — Vylepšené handlery pro discovery a integraci agentů s lepším hlášením chyb
Správa SSH klíčů — Rozšířená služba SSH klíčů s vylepšeným importem a rotačními schopnostmi

Bezpečnostní aktualizace¶

Aktualizovaná autentizační služba s vylepšenou validací tokenů a správou sessions
Vylepšený Entra ID Graph klient s dodatečnými bezpečnostními hlavičkami

Verze 1.0.24¶

Datum vydání: 2026-03-30

Opravy chyb¶

Oprava Entra ID SSO — Vyřešen kritický problém s autentizací Entra ID SSO ovlivňující přihlašovací flow a obnovu tokenů
Vyčištění kódu — Odstraněn zastaralý kód handlerů a nepoužívané endpointy mapování Entra pro čistší codebase

Vylepšení¶

Aktualizované modely schématu s dodatečnými definicemi polí pro lepší integritu dat

Verze 1.0.23¶

Datum vydání: 2026-03-30

Vylepšení¶

Šablony certifikátů a správa expirace — Vylepšená konfigurace šablon certifikátů s lepším sledováním expirace, optimalizacemi plánovače a lepšími indikátory stavu CA integrace
Validace importu certifikátů — Vylepšená služba importu certifikátů s přísnější validací řetězce a lepšími chybovými zprávami
Synchronizace SSLmarket CA — Rozšířený poskytovatel SSLmarket CA s vylepšenou synchronizací produktů a sledováním stavu certifikátů
Rozšířené logování — Vylepšené logování napříč certifikátovými službami pro lepší troubleshooting a audit trail

Opravy chyb¶

Opravena kalkulace stavu certifikátu v X.509 utility funkcích
Vyřešeny problémy se zobrazením dashboardu pro expirující certifikáty
Opraven modal editace certifikátu zachovávající nesprávné hodnoty při uložení

Verze 1.0.22¶

Datum vydání: 2026-03-30

Nové funkce¶

Podpora multi-gateway prostředí — Nová databázová migrace a servisní vrstva pro multi-gateway nasazení s konfigurací gateway specifickou pro prostředí, monitorováním zdraví a prováděním úloh
Monitor zdraví gateway — Real-time monitorování zdraví gateway s sledováním heartbeatu, automatickou detekcí failoveru a Prometheus metrikami
Služba routování gateway — Inteligentní routování požadavků napříč více instancemi gateway s load balancingem a povědomím o prostředí
Exekutor úloh gateway — Distribuovaný framework pro provádění úloh gateway s retry logikou a sledováním stavu
Správa identity providerů — Nové API handlery pro konfiguraci a správu identity providerů

Vylepšení¶

Posílení cipher key resolveru — Kompletní testovací pokrytí pro rozlišení cipher klíčů s 715+ řádky nových testů eliminujících nekonzistence duálního úložiště
Kontroly zdraví databáze — Aktualizované očekávané tabulky a sloupce pro nové databázové schéma související s gateway
Průvodce integrací — Nové vícekrokové UI průvodce integrací pro konfiguraci CA providerů, správců secrets a externích integrací
Oprava derivace klíčů — Vyřešen problém s derivací klíčů ovlivňující šifrovací operace

Bezpečnostní aktualizace¶

Eliminována zranitelnost duálního úložiště cipher klíčů prostřednictvím migrace 000089
Vylepšená autentizační služba s lepší správou sessions

Opravy chyb¶

Opraveny selhání testů v orchestrátoru certifikátů a službách správy konfigurace
Vyřešen problém s přesměrováním EntraID SSO na některých konfiguracích prohlížeče

Verze 1.0.21¶

Datum vydání: 2026-03-26

Nové funkce¶

Azure Resource Discovery — Nové API handlery pro discovery cloudových zdrojů Azure s enumerací Key Vault, certifikátů a secrets
UI průvodce integrací — Vícekrokový průvodce pro konfiguraci integrací s CA providery a správci secrets, včetně výběru typu, konfigurace poskytovatele a kroků revize

Vylepšení¶

Služba CA účtů — Vylepšená správa CA účtů s lepším zpracováním chyb a sledováním stavu
Aktualizace schémat modelů — Aktualizované datové modely napříč SSH klíči, MFA, OAuth, CRL a zero-trust moduly pro lepší konzistenci a validaci
Testovací pokrytí — Rozšířené testovací pokrytí pro poskytovatele integračních služeb, službu offloadu klíčů a operace offloadu secrets

Opravy chyb¶

Opravena nekonzistence modelu audit událostí certifikátů
Vyřešeny problémy se zarovnáním polí modelu objevených certifikátů

Verze 1.0.20¶

Datum vydání: 2026-03-23

Nové funkce¶

Office365 OAuth2 emailové notifikace — Odesílání emailových notifikací přes Microsoft Graph API pomocí OAuth2 client credentials flow místo legacy SMTP; podpora 3 autentizačních metod (client secret, certifikát, managed identity); využívá existující Entra ID infrastrukturu s cachováním spojení a retry logikou; transparentní náhrada — všech 6 email trigger bodů (upozornění na expiraci, incidenty, týdenní reporty, selhání rotace, souhrny discovery, testovací notifikace) funguje automaticky; nový endpoint GET /api/v1/system/email-status a frontend status indikátor v System Outputs → záložka Notifications
SmallStep CA poskytovatel — Integrace open-source step-ca jako backend certifikační autority s podporou provisioners JWK, X5C a OIDC; mTLS autentizace, podepisování, obnova, revokace certifikátů a podepisování CRL s ověřením otisku kořenového certifikátu; ideální pro zero-trust architektury s krátkodobými certifikáty
Multi-target rotace certifikátů — Nasazení certifikátů na 5 typů cílů: Secret Managers (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault), Kubernetes Secrets (TLS/Opaque), Agent Keystores (JKS, PKCS12, Windows), Agent Files (PEM) a Database Wallets (Oracle OCI); výběr režimu obsahu (veřejný, veřejný+řetězec, kompletní řetězec s klíčem, pouze klíč), automatická detekce formátu, politiky opakování s konfigurovatelným počtem pokusů a prodlevami, spouštění post-install příkazů
Enterprise Entra ID správa životního cyklu přihlašovacích údajů — Kompletní správa životního cyklu se stavy (vytvořen, aktivní, expirující, expirovaný, odvolaný, grace period), konfigurovatelná lhůta odkladu (výchozí 30 dní), sledování historie rotace se starými/novými ID klíčů a trasováním workflow, dashboard monitoringu expirace, ochrana idempotence proti duplicitním rotacím a řešení synchronizačních konfliktů lokálního vs. vzdáleného stavu
Prohlížeč compliance reportů — Generování a zobrazení compliance reportů s formátováním na základě šablon, analýza shody certifikátů na úrovni organizace a exportovatelný výstup reportů
Historie provádění rotace — Detailní historie rotace per certifikát s časovými značkami provádění, sledováním stavu (úspěch/selhání/čekání) a vizualizací stavu synchronizace na úrovni cíle
Sledování fáze životního cyklu certifikátu — Nové fáze životního cyklu (stabilní, obnovování, rotace, revokace) brání duplicitním CA požadavkům během probíhajících operací; nezávislé na stavu certifikátu, certifikáty zůstávají platné během přechodů fází

Vylepšení¶

Cíle audit streamů — Nový Elasticsearch cíl se správou index šablon, podpora cluster módu a CosmosDB; nový Syslog cíl s TCP/UDP transportem, podporou formátů CEF a Syslog; rozšířená služba log streamů s validací konfigurace specifickou pro jednotlivé cíle
Vylepšení LDAP autentizace — Rozšířená LDAP služba s vylepšeným zpracováním bind DN, rozlišením členství ve skupinách, flexibilitou konfigurace schématu a lepší diagnostikou chyb připojení
Redesign plánovače notifikací — Vylepšená logika plánování notifikací o expiraci certifikátů s podporou dávkování pro snížení zahlcení výstrahami, integrace JIRA pro vytváření incidentních tiketů a vylepšení e-mailových notifikací
Služba týdenních reportů expirace — Přepracované generování reportů se správou příjemců, přizpůsobitelným obsahem a zlepšenou spolehlivostí doručení
Vylepšení šablon projektů — Rozšířená konfigurace šablon s integrací konvencí pojmenování, pokročilými výchozími nastaveními a vylepšeným workflow aplikace šablony na projekt
Služba konvencí pojmenování — Rozšířený engine konvencí pojmenování s podporou dalších vzorů, validačních pravidel a propojení konvencí se šablonami pro automatické vynucování
Prometheus metriky — Nové histogram a counter metriky pro rotaci certifikátů, compliance reporting a monitorování výkonu audit streamů
CI/CD pipeline — Nový GitHub Actions workflow pro automatizovaný build, testování a nasazení
SSO Provider Modal — Přidána konfigurace LDAP poskytovatele se serverem, bind DN a nastavením schématu přímo z rozhraní konfigurace SSO
WebLogic Deploy krok rotace — Nový typ kroku rotace pro nasazení keystore na Oracle WebLogic Server s automatickou aktualizací konfigurace domény

Bezpečnostní aktualizace¶

Rotace přihlašovacích údajů Entra ID s kompletním audit trailem — každá rotace zaznamenána s aktérem, časovým razítkem, starými/novými ID klíčů a stavem provádění
Operace SmallStep CA logovány do audit streamu s kompletními metadaty požadavku/odpovědi
Fáze životního cyklu certifikátu brání souběžným CA operacím, eliminující race conditions ve workflow obnovy a rotace
Detekce synchronizačních konfliktů Entra s automatickým sledováním nesrovnalostí lokálního vs. vzdáleného stavu

Verze 1.0.19¶

Datum vydání: 2026-03-20

Nové funkce¶

Nasazení Azure Gateway — Multi-regionální infrastruktura Azure Gateway s Terraform moduly pro AKS, Key Vault, PostgreSQL, Redis, síťování, monitoring a správu identit; Helm chart values pro konfiguraci gateway; Azure DevOps CI/CD pipeline pro automatizované nasazení
Key Vault RBAC služba — Granulární řízení přístupu na základě rolí pro operace Azure Key Vault s oprávněními na úrovni jednotlivých tajemství a certifikátů
Key Vault Watch Connector — Real-time synchronizace mezi MazeVault a Azure Key Vault s detekcí změn a automatickou aktualizací tajemství
Engine konvencí pojmenování — Doménově specifická pravidla pojmenování s wildcard pattern matchingem, řazením priorit a vynucováním na úrovni šablon pro konzistentní pojmenování zdrojů napříč projekty
Dashboard záložka reportů — Přepracovaný dashboard reportů se statistikami přehledu certifikátů, interaktivními grafy a exportovatelnými daty reportů
Node.js SDK — Oficiální MazeVault SDK pro Node.js s TypeScript definicemi, podpora autentizace (SRP), organizací, projektů a správy tajemství

Vylepšení¶

Audit log scoping na projekt — Auditní události nyní obsahují vazbu na projekt pro efektivní filtrování per projekt a compliance reporting; existující události zpětně doplněny z vazeb entit
Oprava storage mode pro Orchestrator Mode — Normalizovány nekonzistentní hodnoty storage mode pro nasazení Orchestrator Mode, vyřešeny porušení omezení
Entra Group Mappings — Vylepšená spolehlivost mapování skupin na role s lepším zpracováním chyb a zpětnou vazbou v UI
Zpevnění šifrování konfigurace — Rozšířená služba šifrování konfigurace s dodatečným pokrytím testy a vylepšeným zpracováním chyb pro okrajové případy
Validace importu certifikátů — Vylepšená služba importu certifikátů s přísnější validací řetězce
Aktualizace Go SDK — Aktualizované definice projektů a modelů pro konzistenci s nejnovějším API
Aktualizace Python SDK — Zarovnání modelů s nejnovějším API schématem

Opravy chyb¶

Opraveno zbytečné vytváření prostředí pro nepoužívané projekty
Vyřešen problém s přesměrováním SSO přihlášení Entra ID na určitých konfiguracích prohlížečů
Opraven modál šablony projektu nezachovávající vazby na prostředí při uložení

Verze 1.0.18¶

Datum vydání: 2026-03-14

Vylepšení¶

Zákaznická dokumentace aktualizována — Kompletní návod pro automatizaci certifikátů pomocí ACME s postupem nastavení Kubernetes krok za krokem, příklady cert-manager ClusterIssuer, směrování ACME profilů, řešení problémů a kompletní end-to-end YAML příklady; aktualizovaná API reference certifikátů s ACME endpointy a správou EAB; poznámky k verzím přeformátovány na správné verzovací schéma 1.0.x
Vylepšená integrace Azure Entra ID — Vylepšené zpracování obnovení tokenů, spolehlivější mapování skupin na role, rychlejší přihlašování SSO se sníženou latencí přesměrování a lepší chybové hlášky pro špatně nakonfigurovaná nastavení tenanta

Verze 1.0.17¶

Datum vydání: 2026-03-14

Nové funkce¶

ACME Server (RFC 8555) — MazeVault nyní funguje jako plnohodnotná ACME certifikační autorita, umožňující automatické vydávání certifikátů přes cert-manager a další ACME klienty
External Account Binding (EAB) — Bezpečná registrace clusterů pomocí jednorázových přihlašovacích údajů propojujících ACME klienty s organizacemi a projekty
Směrování ACME profilů — Mapování názvů profilů cert-manageru na šablony certifikátů MazeVault pro automatický výběr CA backendu (cert-manager v1.18+)
Pravidla domén — Konfigurace pravidel pro směrování domén na šablony s podporou wildcardů a priorit
Automatické schválení interních domén — Certifikáty pro domény .local, .internal, .lan a .corp jsou vydány okamžitě bez HTTP-01 výzvy
ADCS most přes ACME — Vydávání certifikátů z Microsoft Active Directory Certificate Services přes standardní ACME protokol
Vylepšení ADCS agenta — DCOM logika opakování pro čekající žádosti o certifikáty s konfigurovatelným intervalem
UI pro správu EAB přihlašovacích údajů — Generování, výpis a odvolání EAB přihlašovacích údajů z webového rozhraní s příklady YAML pro cert-manager

Vylepšení¶

ACME directory endpoint s meta profily pro automatické vyhledávání klienty
JWS middleware s ověřením podpisů ES256 a RS256
Ochrana proti opakování na bázi nonce dle RFC 8555 §6.5
Doručení kompletního PEM řetězce certifikátů pro ACME klienty
Tabulka EAB přihlašovacích údajů se sledováním stavu (Dostupný / Použitý / Odvolaný)
Kopírování jedním kliknutím pro URL ACME adresáře a vygenerované přihlašovací údaje

Bezpečnostní aktualizace¶

EAB HMAC klíče šifrovány v úložišti pomocí AES-256-GCM
EAB přihlašovací údaje jsou jednorázové a podporují expiraci a odvolání
Ověření JWK Thumbprint (RFC 7638) pro vazbu účtu
Všechny ACME operace zaznamenány v auditním logu

Verze 1.0.16¶

Datum vydání: 2026-02-28

Vylepšení¶

Redesign nastavení organizací s navigací pomocí záložek
Karty účtů certifikačních autorit se stavovými indikátory synchronizace
Vylepšené zjišťování produktů CA a spouštění synchronizace přes UI
Optimalizace intervalu heartbeatu agentů pro velké flotily
Ladění pool připojení k databázi pro nasazení s vysokou souběžností

Opravy chyb¶

Opravena validace řetězce certifikátů pro intermediate CA certifikáty
Vyřešen race condition při souběžném plánování rotace tajemství
Opravena invalidace cache OCSP responderu při revokaci certifikátu

Verze 1.0.15¶

Datum vydání: 2026-02-14

Vylepšení¶

Import PFX/PKCS#12 s konfigurovatelným úložištěm klíčů (software / HSM)
Podpora přepsání šablony certifikátu pro výchozí hodnoty na úrovni CA účtu
Vylepšená logika opětovného připojení agenta po přerušení sítě
Rozšířené filtrování auditního logu podle typu události a časového rozsahu

Opravy chyb¶

Opraven export certifikátu s řetězcem pro cross-signed intermediate
Vyřešeno neukládání nastavení šablony projektu po uložení
Opravena deduplikace zjišťování SSH klíčů pro rotované klíče

Verze 1.0.14¶

Datum vydání: 2026-01-31

Vylepšení¶

Vylepšení správy SSH klíčů — sledování a zjišťování autorizovaných klíčů
Vylepšení spouštěčů rotace s ošetřením referenční integrity
Sdílení tajemství po rotaci s automatickým přešifrováním
Vylepšené chybové hlášky pro selhání ověření proxy agenta

Opravy chyb¶

Opraveno zpracování časových zón plánovače rotace pro instalace mimo UTC
Vyřešen nesoulad počtu certifikátů na dashboardu po hromadném importu
Opravena kontrola expirace API tokenu pro servisní identity

Verze 1.0.13¶

Datum vydání: 2026-01-24

Vylepšení¶

Modernizace React importů — optimalizované MUI importy pro tree-shaking
Snížení velikosti frontend buildu (~15% menší bundle)
Vylepšené vyhledávání certifikátů s wildcard SAN matchingem
Rozšířené Prometheus metriky monitoringu s histogram buckety

Opravy chyb¶

Opravena kontrola RBAC oprávnění pro vnořená prostředí projektů
Vyřešeno formátování Terraform exportu pro komplexní hodnoty tajemství
Opraven health check endpoint vracející zastaralý stav Redis

Verze 1.0.12¶

Datum vydání: 2026-01-17

Vylepšení¶

Integrace skenování kontejnerových obrazů Trivy v CI/CD pipeline
Remediace bezpečnostních zranitelností v řetězci závislostí
Vylepšená konfigurace TLS cipher suite s profilem Mozilla Intermediate
Rozšířený rate limiting s algoritmem posuvného okna

Opravy chyb¶

Opraveno plánování obnovy certifikátů s vlastní platností
Vyřešen konflikt synchronizace pro současně editovaná tajemství mezi datacentry
Opravena validace registračního tokenu agenta pro znovu registrované agenty

Verze 1.0.11¶

Datum vydání: 2026-01-10

Vylepšení¶

Monitoring zdraví připojení PostgreSQL s automatickým opětovným připojením
Vylepšení architektury obousměrné synchronizace pro multi-region nasazení
Opravy instalačního skriptu agenta pro air-gapped prostředí
Vylepšení onboarding procesu pro scénáře vzdáleného nasazení

Opravy chyb¶

Opraven rollback databázové migrace při selhání upgradu
Vyřešena synchronizace LDAP skupin nereflektující změny členství
Opravena paginace seznamu certifikátů pro projekty s > 1000 certifikáty

Verze 1.0.10¶

Datum vydání: 2026-01-03

Vylepšení¶

Rozšířená detekce externích změn pro certifikáty spravované CA
Vylepšená dokumentace hodnot Helm chartu s inline komentáři
Dávkování notifikací o expiraci certifikátů pro snížení únavy z alertů
Aktualizované Go závislosti s bezpečnostními záplatami

Opravy chyb¶

Opraven CRDT merge pro souběžné vytváření verzí tajemství
Vyřešena logika opakování synchronizace Azure Key Vault pro přechodné selhání
Opraven OCSP responder vracející nesprávný stav pro obnovené certifikáty

Verze 1.0.9¶

Datum vydání: 2025-12-15

Nové funkce¶

Systém šablon certifikátů — Předkonfigurované certifikátové profily pro běžné případy použití (Web Server, Client Auth, Code Signing, Email/S-MIME)
Hromadné operace s certifikáty — Import a správa certifikátů hromadně přes PEM bundly
Vylepšené zjišťování agentů — Automatické zjišťování certifikátů v infrastruktuře spravované agenty
Vylepšení synchronizace — CRDT synchronizace mezi více datacentry s vylepšeným řešením konfliktů
Export do Terraform — Export konfigurací projektů jako Terraform HCL pro infrastructure-as-code workflow

Vylepšení¶

Vylepšená validace importu certifikátů a hlášení chyb
Zvýšený výkon OCSP responderu s cachováním odpovědí
Aktualizovaný RBAC s granulárními oprávněními pro správu certifikátů
Vylepšené auditní logování se strukturovaným JSON výstupem
Rozšířené endpointy kontroly zdraví se stavem na úrovni komponent

Bezpečnostní aktualizace¶

TLS 1.3 jako výchozí protokol
Vylepšená CSRF ochrana s double-submit cookie pattern
Rozšířený rate limiting s konfigurací per endpoint
Aktualizované kryptografické závislosti

Verze 1.0.8¶

Datum vydání: 2025-11-20

Nové funkce¶

Integrace s externí CA — Propojení s DigiCert, Venafi, Microsoft ADCS a dalšími externími certifikačními autoritami
Podpora HSM — Integrace Hardware Security Module pro ochranu klíčů (PKCS#11, Azure Managed HSM)
ACME protokol — Automated Certificate Management Environment pro automatizované vydávání certifikátů
Vícefaktorová autentizace — MFA založená na TOTP pro zvýšenou bezpečnost účtů

Vylepšení¶

Přepracované rozhraní pro správu certifikátů
Vylepšené plánování rotace tajemství
Rozšířený API rate limiting
Rozšířená integrace s Azure Key Vault

Verze 1.0.7¶

Datum vydání: 2025-09-10

Nové funkce¶

Zero-Knowledge šifrování — Šifrování na straně klienta pro tajemství osobního trezoru
Podpora SCEP protokolu — Simple Certificate Enrollment Protocol pro správu certifikátů zařízení
Podpora EST protokolu — Enrollment over Secure Transport pro moderní registraci certifikátů
Proxy agenta — Agenti mohou zprostředkovat přístup k tajemstvím pro lokální aplikace

Vylepšení¶

Vylepšený systém databázových migrací
Rozšířené logování a monitoring
Aktualizované manifesty pro Kubernetes nasazení
Vylepšení výkonu pro velká úložiště certifikátů

Verze 1.0.6¶

Datum vydání: 2025-06-15

Nové funkce¶

Synchronizace více datacenter — Obousměrná synchronizace mezi instalacemi MazeVault
Azure Entra ID SSO — Single Sign-On s Azure Active Directory
RBAC na úrovni projektů — Granulární řízení přístupu na základě rolí per projekt
Distribuce CRL — Automatizované generování a distribuce Certificate Revocation List

Vylepšení¶

Vylepšený dashboard s aktualizacemi stavu v reálném čase
Rozšířené vyhledávání a filtrování certifikátů
Aktualizovaná API dokumentace se specifikací OpenAPI 3.0
Vylepšená bezpečnost kontejnerových obrazů

Verze 1.0.5¶

Datum vydání: 2025-03-20

Nové funkce¶

OCSP Responder — Real-time Online Certificate Status Protocol responder
Verzování tajemství — Kompletní historie verzí s možností rollbacku
Správa agentů — Centralizovaná registrace a monitoring agentů
LDAP integrace — Podpora autentizace přes adresářové služby

Verze 1.0.4¶

Datum vydání: 2024-12-10

Nové funkce¶

Interní certifikační autorita — Kompletní PKI s podporou root a intermediate CA
Správa životního cyklu certifikátů — Žádost, schválení, vydání, obnova a revokace certifikátů
Helm charty — Standardizované nasazení v Kubernetes přes Helm

Verze 1.0.3¶

Datum vydání: 2024-09-15

Nové funkce¶

Integrace s Azure Key Vault — Synchronizace tajemství s Azure Key Vault
Rotace tajemství — Automatizovaná a manuální rotace tajemství
Kubernetes nasazení — AKS nasazení s Terraform

Verze 1.0.2¶

Datum vydání: 2024-06-20

Nové funkce¶

Řízení přístupu na základě rolí — Uživatelské role a oprávnění
Správa projektů — Organizace tajemství do projektů
API v1 — Kompletní REST API pro správu tajemství

Verze 1.0.1¶

Datum vydání: 2024-03-01

Úvodní vydání¶

Šifrované úložiště tajemství s AES-256-GCM
Webové správcovské rozhraní
PostgreSQL backend s Redis cachováním
Docker Compose nasazení
Lokální autentizace s SRP protokolem

Zásady podpory

MazeVault podporuje aktuální verzi a jednu předchozí minor verzi. Zákazníkům na starších verzích doporučujeme provést upgrade pro získání bezpečnostních aktualizací a nových funkcí.