Operations

Security

Understand the security principles and planned controls shaping the StrataGateway cloud infrastructure platform.

Planned

Development Preview

StrataGateway security architecture is currently being designed and implemented alongside the platform. Authentication models, permissions, network controls, infrastructure isolation, encryption behavior, audit capabilities, security tooling, and operational procedures may change before public release.

Jump to article

Overview

Security is intended to be part of the StrataGateway platform foundation rather than an optional add-on. The platform is being designed with security principles embedded throughout the infrastructure lifecycle.

Secure-by-default infrastructure
Least-privilege access
Clear authentication boundaries
Network isolation
Protected credentials
Auditable infrastructure actions
Infrastructure-level defense in depth
Transparent documentation
Predictable security behavior

StrataGateway security architecture is currently being designed and implemented alongside the platform. Authentication models, permissions, network controls, infrastructure isolation, encryption behavior, audit capabilities, security tooling, and operational procedures may change before public release.

Do not imply that every security control described below is currently deployed in production. Do not claim certifications, audits, compliance programs, penetration tests, or external security reviews unless they actually exist.

Shared responsibility

The conceptual shared-responsibility model defines boundaries between platform and customer obligations:

AreaStrataGateway ResponsibilityCustomer Responsibility
Physical infrastructurePlatform / provider layerN/A where applicable
Cloud infrastructure platformPlatform architecture and service controlsCorrect resource configuration
Guest operating systemInfrastructure boundaryUpdates, packages, configuration
ApplicationsInfrastructure availabilityApplication security
CredentialsPlatform authentication mechanismsCredential protection and rotation
Network configurationPlatform networking capabilitiesFirewall and exposure decisions
Application dataInfrastructure protection mechanismsData classification and application-level protection

Do not claim StrataGateway currently owns or operates physical datacenters unless verified. Use general wording such as “Underlying infrastructure layer” where necessary. The exact responsibility model will depend on the final service and infrastructure architecture.

Account security

Planned account-level protections:

ControlStatus
Secure loginIn Development
Multi-factor authenticationPlanned
Session managementIn Development
Account recoveryPlanned
Enterprise SSOUnder Evaluation

Do not claim MFA is already implemented unless verified. If MFA does not exist yet, describe it as “Multi-factor authentication \u2014 Planned”. Do not invent OAuth, SSO, passkeys, hardware-key support, or enterprise identity integrations.

API authentication

Programmatic platform access is intended to use secure API credentials.

API tokens
Limited credential exposure
Environment variables
Token rotation
Revocation
Separation between development and production credentials

Never embed API tokens directly into source code, public repositories, frontend bundles, container images, or documentation examples.

Illustrative environment variable

Illustrative environment variableBash
STRATA_API_TOKEN=your_token_here

Do not expose fake production credentials.

Authentication documentation

Infrastructure isolation

StrataGateway is being designed so customer workloads and platform resources are separated through appropriate infrastructure boundaries.

Potential security boundaries:

Compute workloadsNetworkingStorageControl-plane operations

Do not claim specific hypervisor isolation mechanisms. Do not claim dedicated hardware isolation. Do not claim confidential computing. Do not name virtualization technologies unless the actual architecture already uses and documents them. Exact isolation mechanisms will depend on the final compute architecture.

Network security

Planned network-security principles:

Explicit network configurationPrivate networkingControlled public exposureFirewall policiesInfrastructure segmentationMinimized unnecessary exposure

Conceptual flow:

Conceptual flow

Conceptual flowtext
Internet
→ Public Network Boundary
→ Firewall Policy
→ Resource
→ Private Network

Do not claim network intrusion detection, WAF, IDS, IPS, zero-trust networking, or traffic inspection unless actually implemented.

Networking documentation

Firewalls

Firewalls fit into the security model as the primary mechanism for controlling traffic exposure.

Inbound rules
Outbound rules where supported
Explicit protocol and port exposure
Source restrictions
Minimal-access configurations

Illustrative principle:

Expose only the services that a workload actually requires.

Simple conceptual example:

Planned

Illustrative firewall policy

Illustrative rules

Illustrative rulestext
SSH:
  TCP 22
  Source: Trusted administrative network

HTTPS:
  TCP 443
  Source: Public internet

Do not imply these rules are automatically created.

Firewalls documentation

SSH access

Recommended SSH security practices:

Prefer SSH keys over passwords
Protect private keys
Use modern key types
Remove unused keys
Rotate compromised credentials
Restrict administrative network access where possible

StrataGateway should only receive public SSH key material. Private keys must never be uploaded to the platform. Do not claim StrataGateway manages private keys.

SSH Keys documentation

Data protection

Intended data-protection principles:

Data at restData in transitBackupsInfrastructure metadata

Do not state specific encryption algorithms unless actually implemented. Do not state AES-256, TLS 1.3 only, customer-managed keys, or HSM-backed keys unless verified. Data protection mechanisms are being designed for both stored data and platform communications. Exact cryptographic implementations and key-management architecture will be documented before public release.

Backups documentation

Secrets and credentials

Where secrets should not be stored:

Secrets should not be stored in Git repositories
Secrets should not be stored in source code
Secrets should not be stored in documentation
Secrets should not be stored in container images
Secrets should not be stored in public environment files
Secrets should not be stored in shell history where avoidable

Recommended approaches:

Environment variablesCI/CD secret storageDedicated secret-management toolingScoped credentialsCredential rotation

A dedicated StrataGateway secrets-management product is not currently documented as part of the platform. Do not claim StrataGateway provides a managed Secrets product unless one actually exists.

Platform security

Platform security extends beyond individual customer resources:

Control-plane accessService-to-service authenticationInternal network boundariesCredential handlingInfrastructure hardeningDependency managementOperational access controls

Do not expose internal security architecture details that have not been implemented. Do not invent internal SOC, 24/7 security team, automated threat intelligence, proprietary detection systems, SIEM stack, or security certifications. Platform security architecture will continue to evolve as StrataGateway moves toward public availability.

Logging and auditability

Planned importance of recording sensitive infrastructure actions. Potential future audit events:

Authentication activity
API token creation
API token revocation
Instance creation
Instance deletion
Firewall modifications
SSH key changes
Network configuration changes
Backup operations
Planned

Planned

The final audit-log event schema and retention model are not finalized. Do not claim a production audit log currently exists.

Illustrative audit event

Illustrative event

Illustrative eventJSON
{
  "event": "firewall.updated",
  "resource_id": "fw_example",
  "actor": "account_user",
  "timestamp": "2026-07-27T18:30:00Z"
}

Do not present this as the final schema.

Security updates

Distinction between platform and guest-system updates:

StrataGateway

Responsible for updates within infrastructure components it operates.

Customer

Responsible for operating-system packages, applications, dependencies, and workload configuration inside customer-controlled environments.

Do not claim automated guest OS patching. Do not claim live patching. Do not claim managed vulnerability remediation. Keeping operating systems and application dependencies updated remains a critical customer responsibility.

Incident response

A formal incident-response process is intended to be part of platform operations.

Potential lifecycle:

1.

Detection

2.

Investigation

3.

Containment

4.

Remediation

5.

Recovery

6.

Review

Detailed incident-response procedures are still being developed. Do not claim guaranteed response times, 24/7 SOC coverage, contractual incident SLAs, or specific notification windows unless verified. Customer-visible incidents affecting platform availability should be communicated through appropriate service-status mechanisms once those systems are operational.

Security reporting

Responsible reporting of potential security issues is important.

Inspect the project before adding any contact address. If a verified security-specific email such as [email protected] does NOT already exist publicly in the project: Do NOT invent it. Instead use: “Security reporting instructions will be published before public launch.” If an appropriate real contact method already exists in the project, reuse it. Do not create vulnerability-reward or bug-bounty claims. Do not claim a bug bounty exists.

Potential future topics:

Responsible disclosureVulnerability reportingResponse workflowPublic security contact
Planned

Planned

Security checklist

Practical checklist for infrastructure security:

\u2713Protect account credentials
\u2713Enable stronger authentication when available
\u2713Store API tokens securely
\u2713Rotate credentials when necessary
\u2713Use SSH keys
\u2713Protect private SSH keys
\u2713Restrict firewall exposure
\u2713Keep guest operating systems updated
\u2713Protect backups
\u2713Review infrastructure changes
\u2713Avoid storing secrets in source control
\u2713Maintain application-level security controls

Do not add interactive state unless the existing docs system already supports it. This is a visual checklist.

Security and DDoS protection

General platform security and DDoS protection are related but distinct.

Security

Broad protection of accounts, infrastructure, access, data, and operations.

DDoS Protection

Network-level availability protection against certain denial-of-service conditions.

Do not claim specific mitigation capacity. Do not claim always-on scrubbing. Do not claim automatic mitigation exists unless verified. DDoS Protection has its own dedicated documentation.

DDoS Protection documentation

Security and monitoring

Conceptual relationship:

Monitoring

Operational visibility

Security controls

Risk reduction

Auditability

Understanding sensitive actions

Incident response

Recovery and remediation

Do not claim a SIEM or threat-detection platform exists.

Monitoring documentation

Was this page helpful?