Security philosophy
Security at AstraNET is treated as an operational process rather than a marketing label.
Security outcomes depend on the actual operating setup, its access controls, update process, recovery options, and documentation. This page describes considerations to scope for each deployment, not a claim that every control is active everywhere.
Deployment isolation
How customers and workloads are separated depends on the architecture of the individual deployment.
Access
Access requirements must be specified and checked against the actual environment.
- Identify who needs production access and why.
- Determine whether multi-factor authentication is supported and enabled for administrative access.
- Specify individual accounts and appropriate privileges for the deployment.
- Agree on administrative logging and review needs.
Secrets
The handling of credentials, tokens, and keys needs to be defined for each environment; sensitive values should not be published in source code or documentation.
Updates and vulnerabilities
Update and vulnerability response responsibilities depend on the agreed operating model.
- Determine who reviews dependencies for known vulnerabilities.
- Define how patches will be tested before production rollout.
- Agree on priorities and emergency update procedures.
Backups
Backup availability and restore capability depend on the actual operating setup; no blanket backup or tested-restore guarantee applies.
- Determine whether a backup exists and what it covers.
- Agree on encryption and retention requirements where backups are in scope.
- Define restore procedures and tests where recovery is in scope.
- Clarify who controls backups and the recovery path.
Logging and monitoring
Telemetry needs, such as service availability, resource use, errors, and administrative events, depend on the deployment.
Where logs are enabled, their access and retention must be specified for the operating setup.
Data location
Where data is processed and stored is a deployment decision: customer-selected infrastructure, or an agreed hosting environment.
Concrete locations and providers must be identified for the actual deployment before location commitments are made.
Security reporting
Reports about potential security issues in AstraNET systems are welcome and handled seriously.
Please send a description of the issue and a contact for follow-up to hi@astranet.io. Do not include credentials in your initial message.
Compliance
Architectures can be designed around customer-specific security and regulatory requirements.
Certifications are listed only when they exist, with scope and certificate details.