Security Architecture

VaultGuard360 is designed with a security-first architecture. It deploys entirely within your Azure tenant, operates read-only on Key Vault metadata, and is built so that the publisher has no access to your environment or data.

Security Model

VaultGuard360 deploys as an Azure Managed Application into your subscription. Every component runs within your tenant — no data leaves your environment except outbound alert notifications (email, webhooks) that you configure.

Core guarantees:

• All compute, storage, and monitoring run in your Azure subscription
• The application is read-only by design — it can list metadata but never retrieve secret values
• The publisher has zero access to your deployment (no Contributor, no JIT, no standing permissions)
• There are no telemetry calls, license checks, or analytics calls to the publisher

What VaultGuard360 Can and Cannot Access

Can access (read-only metadata)

• Item names (secret names, certificate names, key names)
• Expiration dates
• Vault names and subscription IDs
• Admin email addresses you configure

Cannot access

• Secret values
• Certificate contents or private keys
• Key material
• Any resource outside the Key Vaults you grant access to

The assigned RBAC roles do not include value-retrieval permissions. This is a hard constraint enforced by Azure's permission model — not a policy or configuration choice.

Authentication

User Authentication

Dashboard access is protected by Microsoft Entra ID SSO, configured automatically during deployment.

Service Authentication

The application uses a user-assigned managed identity for all internal authentication. No passwords, API keys, or connection strings are used for Key Vault access.

RBAC (Least Privilege)

Note: Key Vault Reader is the only role granted on your subscriptions. The application does not use the Azure Reader role for vault access.

Additional roles scoped to resources within the managed resource group only are required for internal operations and email delivery. These have no access outside the managed resource group.

Zero Publisher Access

The publisher (Sentinel Vault Systems) has zero access to your managed resource group:

• No Contributor role
• No JIT (Just-In-Time) access
• No standing permissions of any kind

This is configured as "No access" in the Azure Marketplace Partner Center. The publisher cannot view, modify, delete, or query any resources in your deployment.

The customer has ReadOnly access to the managed resource group — you can view resources and query logs, but cannot modify or delete anything (enforced by Azure deny assignments).

Data Protection

Data Collected (Metadata Only)

Encryption

• At rest: AES-256 encryption (Azure Storage Service Encryption)
• In transit: TLS 1.2+ enforced, HTTPS only

Data Residency

All data is stored in encrypted storage within your managed resource group, in the Azure region you select during deployment. Email delivery data location is separately selectable (US, Europe, Asia Pacific, Australia, UK). The publisher does not host or replicate customer data.

Credential Handling

Integration credentials (webhook secrets, SMTP passwords) are stored encrypted within your subscription and are never returned in API responses. The configuration export tool excludes all credentials.

Network Security

Baseline Controls (All Tiers)

• HTTPS only, TLS 1.2 minimum enforced
• No inbound ports besides HTTPS (443)
• Security headers: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Cache-Control
• SSRF protection on webhook and SMTP targets
• Request payload size limits with input validation

Security Posture by Tier

See Network Isolation for full Enterprise private networking documentation.

Defense in Depth

VaultGuard360 implements multiple layers of hardening controls:

• HMAC-signed webhooks — all outbound webhook payloads are cryptographically signed so receivers can verify authenticity
• Content Security Policy (CSP) — strict browser-side protections against XSS and injection
• SSRF blocking — webhook and SMTP targets are validated to prevent server-side request forgery
• KQL injection prevention — parameterized queries prevent log query injection attacks
• Rate limiting — API endpoints enforce request rate limits to prevent abuse
• Input validation — all user inputs validated with strict schemas and size limits
• Fail-closed authentication — enforced at the platform level, before application code runs
• Audit logging — all scans and configuration changes logged with correlation IDs, 365-day retention
• No runtime dependencies — no external package downloads during operation

Compliance Alignment

VaultGuard360 supports your compliance efforts. It does not hold independent certifications.

Shared Responsibility

Threat Model

Blast radius if compromised: An attacker could access item names and expiry dates. They cannot access secret values, modify resources, or escalate privileges.