Security | atoship

1. Overview

atoship handles shipment data on behalf of merchants: sender and recipient addresses, order contents, carrier credentials and payment details. This page describes the controls that protect that data. It is written to be checked, not to reassure — each item below is a control that is in place today.

2. Encryption

In transit

All traffic to atoship is served over TLS. Public traffic terminates at a managed edge network that provides TLS termination and a web application firewall; the origin server address is not published in any DNS record.

At rest

Carrier and sales-channel credentials, and stored payment tokens, are encrypted with AES-256-GCM — authenticated encryption with a per-record random initialisation vector — before they are written to the database.
Account passwords are never stored; only salted one-way hashes are kept.
Database and application storage volumes are encrypted at rest with AES-256 by the cloud provider.
Off-site backups are stored with server-side AES-256 encryption at rest.

Key management

Encryption keys and all service credentials are held in a dedicated secrets manager, separated by environment and injected into the application at process start. Access to the secrets manager is per-individual. Credential rotation follows a documented order — rotate at the provider, then in the secrets manager, then restart — so that a rotation cannot leave a window in which the old key is already invalid and the new one is not yet loaded.

3. Access control

The highest privilege level cannot be reached with a password alone: two-factor authentication is mandatory for it, and is held only by named individuals. Automated testing runs under a separate, clearly identified service account that does not hold that level.
Authorisation is role-based and enforced on the server for every request, not in the browser. Administrative capability is limited to a small number of named accounts.
Passwords must be at least 12 characters and contain a letter, a digit and a special character, and administrator passwords expire after 90 days. Changing a password invalidates existing sessions for that account: every session token is checked against the account’s last password change and rejected if it predates it.
Time-based one-time-password (TOTP) two-factor authentication is available on all accounts.
Support access to a customer account requires the highest privilege level, requires a written business justification, and writes an audit record naming the operator, the account, the reason, the source address and the user agent before the session is issued. If that audit record cannot be written, the access is refused.

4. Network and infrastructure

Databases and internal caches listen on the loopback interface only and are not reachable from the public internet.
The application port is closed at the cloud firewall; all external traffic must pass through the edge network.
Host access is by SSH key only. Password authentication is disabled.
Host-level audit rules monitor scheduled tasks and system configuration for modification.

5. Logging, monitoring and incident response

An audit log records authentication, role and permission changes, credential access, support impersonation and data exports, with actor, target, timestamp, source address and user agent. Security-relevant entries are retained for 365 days.
Graded alerts are raised to an operations inbox and de-duplicated, so that a sustained fault does not bury itself in noise.
Infrastructure thresholds are evaluated every ten minutes; label-purchase availability is evaluated every five minutes per carrier route, so a degraded carrier integration is detected from real traffic rather than from customer reports.
A written incident-response runbook defines severity, containment, credential-rotation order, evidence collection from the audit log, and notification. It is updated after each incident, and it carries an explicit register of known control gaps so that no control is claimed that is not actually in place.

6. Backups and continuity

The production database is backed up hourly and copied to object storage operated by a different cloud provider in a different geography, so that a provider-level or regional failure cannot take both the system and its backups.
Continuous write-ahead-log archiving supports point-in-time recovery; a warm standby database is maintained in a separate location.
Backups run hourly and are archived off-site, with continuous write-ahead-log archiving for point-in-time recovery. We do not publish a recovery time objective, because we have not yet measured one in a full restore drill; stating a number we have not tested would be worse than saying so.
Backups are reachable only with scoped credentials held in the secrets manager, and are encrypted at rest by the storage provider.

7. Secure development

Static application security testing and secret scanning run on every proposed change and weekly on a schedule. Their findings are recorded in a register with an owner and a remediation deadline set by severity, and the build fails when a finding is not in that register, is past its deadline, or when a scanner produced no result at all. The bar is that every finding is tracked and owned, not that the count is zero.
Secret scanning runs over the full repository history, not only the changed lines, on every proposed change and weekly.
Production dependencies are audited for known vulnerabilities when the dependency manifest changes and weekly on a schedule, and automated update proposals are raised and reviewed.
Database schema changes are gated by a guard that refuses destructive migrations.

8. Data retention and deletion

Shipment data is retained for as long as it is needed to produce and support the shipment, to meet carrier dispute and claim windows, and to satisfy financial record-keeping obligations. Where a sales channel imposes a retention limit on recipient personal information, an automated job erases that information once the limit has passed — the recipient block, the shipping label document itself, and the copies held in the import staging tables — leaving the carrier, service, cost and tracking records that billing and dispute handling depend on.

Security-relevant audit records are retained for 365 days. Operational logs are pruned on a shorter schedule. Customers may request deletion of their data as described in the Privacy Policy.

9. Sub-processors

atoship transmits shipment data to the carriers and sales channels a customer chooses to connect, and to the infrastructure, payment and communication providers required to operate the service. Data is shared with a carrier or channel only to the extent needed to produce a label, track a shipment or reconcile a charge.

10. Reporting a vulnerability

If you believe you have found a security issue, please report it to [email protected] with enough detail to reproduce it. We will acknowledge your report and keep you informed while we investigate. Please do not access, modify or delete data belonging to anyone else, and please give us a reasonable opportunity to remediate before public disclosure.