Resumo em português: este documento reúne as políticas de segurança da informação da Sky Altus (segurança, controle de acesso, classificação e criptografia de dados, resposta a incidentes). Está em inglês porque é o formato exigido pelas plataformas parceiras.
This program applies to all Sky Altus systems, servers, workstations and personnel that store or process customer data, marketplace data or credentials. It is reviewed at least annually and whenever the infrastructure changes materially.
1. Information Security Policy
1.1 Objectives
- Protect the confidentiality, integrity and availability of customer and marketplace data.
- Comply with the LGPD (Law 13.709/2018) and with the data policies of Shopee Open Platform and TikTok Shop Partner Center.
- Limit data collection and retention to what each contracted service requires.
1.2 Roles
| Role | Responsibility |
|---|---|
| Managing Director | Owns this program, approves exceptions, is the incident commander and the LGPD data protection officer. |
| Infrastructure operator | Applies patches, manages firewall/TLS/backups, reviews access and logs. |
| All personnel and contractors | Follow the security baseline, report incidents immediately, use only named accounts. |
1.3 Infrastructure
- Dedicated servers administered by Sky Altus (Linux, Ubuntu LTS), with automatic security updates.
- All public traffic terminates on a reverse proxy (Caddy) with TLS 1.2+ and automatic certificate renewal; HTTP is redirected to HTTPS; HSTS and security headers are enabled.
- Application services bind to localhost or private interfaces only; databases (PostgreSQL) are never exposed to the internet.
- Host firewall allows only 22 (SSH, key-only), 80 and 443. Untrusted code runs in an isolated sandbox (gVisor).
- Third-party tenants on shared hardware are isolated in separate system containers with their own network and credentials.
1.4 Network segregation and threat monitoring
- Public edge (reverse proxy) is separated from application services and from the database tier.
- Centralized metrics and logs (Prometheus, Loki, Grafana) with alerting on failed logins, service failures and resource anomalies.
- Brute-force protection on SSH and application logins; rate limiting at the proxy.
1.5 Endpoint security baseline
- Workstations: Microsoft Defender (or equivalent) active with real-time protection; full-disk encryption; automatic OS updates; screen lock after 5 minutes.
- Passwords: minimum 12 characters, unique per system, stored in a password manager; multi-factor authentication required on marketplace, cloud, e-mail and source-control accounts.
- Clear-desk and clear-screen practice; no customer data on removable media.
1.6 Secure development
- Source code in private repositories with mandatory review before deployment; secrets never committed (environment files with restricted permissions, outside the repository).
- Dependencies pinned and updated periodically; automated tests run before release.
1.7 Backups and continuity
- Daily database backups, encrypted, retained for 30 days, with periodic restore tests.
- Infrastructure configuration is versioned so services can be rebuilt on a new host.
2. Access Control Policy
- Least privilege: each person and service receives only the permissions required for its function; marketplace API scopes are limited to those the contracted feature uses.
- Named accounts: no shared administrative accounts; server access by personal SSH key only, passwords disabled for SSH.
- Application roles: customer users see only the stores of their own organization (row-level security in the database); Sky Altus staff access to customer data is limited to support tasks and logged.
- Joiner / mover / leaver: access granted on written approval; reviewed quarterly; revoked within 24 hours of role change or departure, including rotation of any shared secret the person could have known.
- Marketplace authorization: obtained only through the marketplace's official OAuth flow; sellers can revoke it at any time and Sky Altus deletes the token within 7 days.
3. Data Classification and Encryption Policy
| Class | Examples | Handling |
|---|---|---|
| Restricted | API tokens and secrets, passwords, buyer personal data (name, address, phone), tax IDs | Encrypted in transit (TLS) and at rest (AES-256-GCM for tokens; encrypted volumes/backups); access logged; never in logs, tickets or chat; never sent to AI providers. |
| Confidential | Orders, settlements, costs, margins, ad metrics, creator collaboration data | Encrypted in transit; database access restricted to internal network; shared only with the owning customer. |
| Internal | Source code, documentation, configuration | Private repositories, named access. |
| Public | Website content, marketing material | No restriction. |
- Encryption keys are stored outside the code base in files readable only by the service account, and rotated on suspected compromise or personnel change.
- Personal data is retained only for the periods defined in the Privacy Policy and deleted or anonymized afterwards.
4. Incident Response Policy
4.1 Definition
A security incident is any confirmed or suspected unauthorized access, disclosure, alteration or loss of data, or any event that affects the availability of the Service.
4.2 Roles
| Role | Person | Duties |
|---|---|---|
| Incident commander | Managing Director | Declares the incident, coordinates response, approves external communication. |
| Technical lead | Infrastructure operator | Containment, forensics, recovery. |
| Communications | Managing Director | Notifies customers, marketplaces and authorities. |
4.3 Reporting channels
- Internal: immediate message to the Managing Director plus an entry in the incident register.
- External: [email protected] (monitored on business days; urgent reports are escalated by phone).
4.4 Procedure
- Detect and record — open an incident record with time, source and affected systems.
- Contain — isolate the affected service, revoke or rotate compromised credentials and tokens, block malicious sources.
- Assess — determine data involved, number of data subjects and root cause; classify severity (low / medium / high).
- Notify — affected customers and the marketplaces involved as soon as possible and within 72 hours of confirmation; the Brazilian Data Protection Authority (ANPD) and data subjects when required by LGPD art. 48.
- Recover — restore from backups if needed, verify integrity, resume service.
- Review — post-incident report within 10 business days with corrective actions and owners; update this program if required.
4.5 Testing
The procedure is reviewed and exercised (tabletop) at least once a year.
5. Vulnerability and Threat Management
- Operating system security patches are applied automatically (unattended upgrades); other packages are reviewed and updated at least monthly.
- Application dependencies are scanned for known vulnerabilities on every build (npm audit / pip audit) and updated within 7 days for critical or high severity, 30 days for the rest.
- Exposed services and open ports are reviewed monthly; an external port scan of the public address is run quarterly.
- Security advisories from marketplace platforms, Ubuntu and the software vendors in use are monitored; findings are recorded with severity, owner and due date and tracked to closure.
- Threat monitoring: centralized logs and alerts (failed logins, unusual traffic, service crashes) are reviewed by the infrastructure operator; suspicious sources are blocked at the firewall and proxy.
6. Compliance and review
- Violations of this program are treated as misconduct and may lead to termination of access or contract.
- Exceptions require written approval from the Managing Director, with an expiry date.
- Next scheduled review: September 2027.