Selltics Sign in
Legal

Information Security Policy

Effective date:

1. Purpose and scope

This policy describes the technical and organisational measures that protect the Selltics platform — this website, the dashboards, the sign-in service, the Selltics AI assistant, and the data pipelines behind them — and the customer data they process. It applies to all production systems operated by Individual Entrepreneur Myroshnichenko Dmytro.

It is published so customers and reviewers can see what we actually do, stated plainly. Where a common control is not in place, we say so rather than imply it; the trust center keeps an explicit list of claims we do not make yet. Related documents: the Privacy Policy, the Data Processing Addendum, and the pre-filled security questionnaire.

2. Governance

Selltics is operated by Individual Entrepreneur Myroshnichenko Dmytro as a single-operator organisation: one operator owns security end to end — architecture, deployment, access, and incident handling — so responsibility is never diffused across teams. Security questions reach the operator directly at support@selltics.net.

This policy is reviewed at least annually, and additionally after any security incident and after any significant architecture change.

3. Access control and authentication

Customer sign-in

  • Sign-in supports two methods: email and password or Google OAuth.
  • Passwords are stored only as argon2id hashes — never in plaintext, never recoverable. A password stored before the move to argon2id was a bcrypt hash; it is verified once more and replaced by an argon2id hash at the next successful sign-in.
  • Passwords must be 12 to 128 characters long, with no composition rules; one that contains the account's email name, the user's name or "selltics" is refused. Every new password is checked against known breached passwords through the Pwned Passwords range API, which receives only the first 5 characters of its SHA-1 hash, with a bundled list of common passwords as the fallback.
  • Sessions use short-lived JWT access tokens (15 minutes) and refresh tokens valid for 7 days, rotated on every use. Each session is a server-side record that ends after 7 days without use and at the latest 30 days after sign-in, and can be revoked; a password reset revokes every session, a password change every other one. Refresh tokens are stored only hashed.
  • New accounts must confirm their email address before their first sign-in: a password sign-up receives a single-use confirmation link and no session until it is followed. A Google account counts as confirmed when Google reports the address as verified, and a sign-up with a valid invitation to the same address confirms it.
  • Authentication endpoints are protected by a Cloudflare Turnstile challenge.

Rate limits

Requests are rate-limited per IP, keyed on the real client IP provided by Cloudflare:

  • Global API: 60 requests/minute.
  • Login: 5 attempts/minute.
  • Registration: 3 attempts/minute.
  • Token refresh: 30 requests per 5 minutes.

Brute-force lockouts

Failed sign-ins are tracked in Redis independently of rate limits:

  • Maximum 20 failed attempts per IP per 15 minutes.
  • Maximum 5 failed attempts per account per 15 minutes.
  • Exceeding either threshold triggers a 15-minute lockout.

Independently of those counters, the account itself is locked for 15 minutes after 10 consecutive failed password attempts, a state kept in the account record; the account holder is notified by email.

Two-factor authentication

  • Two-factor authentication uses an authenticator app: time-based one-time codes (TOTP, RFC 6238). There is no SMS factor and no hardware-key factor.
  • Mandatory for accounts with a connected Amazon account. Connecting an Amazon account, or reauthorizing an existing connection, requires a session that has passed two-factor authentication. This is enforced server-side by the API, not only by the interface.
  • An account that already has access to a connected Amazon account but no active two-factor authentication (never set up, or reset) must enroll before it can continue to use the product. If the platform cannot determine whether an account has such access, the request is refused rather than allowed.
  • For accounts without a connected Amazon account, two-factor authentication is optional.
  • The authenticator secret is encrypted by the application with AES-256-GCM under a key kept as a SealedSecret; recovery codes are stored only as keyed hashes (HMAC-SHA256) and work once each.
  • A code that has already been accepted is refused if presented again.
  • "Trust this device" skips the code on that browser for 30 days; the period does not extend with use, and only a hash of the device token is stored.
  • Ten consecutive wrong codes pause two-factor sign-in for the account for 15 minutes.
  • A lost authenticator is covered by the recovery codes first. If both are lost, support resets two-factor authentication only after a manual identity check: the request must come from the account's email address, and that address is told of the request and given 24 hours to object before the reset is made. The reset ends every session, and an account with a connected Amazon account must enroll again before it can continue.

Operator access

Administrative and diagnostic access goes over a private Tailscale network (tailnet): the cluster joins it through the Tailscale Kubernetes operator, and cluster access is granted per tailnet identity. Internal admin interfaces are reachable only from that network. There are no unauthenticated admin surfaces exposed to the Internet.

4. Infrastructure security

  • Single point of entry. All public traffic enters through one Cloudflare Tunnel; connections are encrypted in transit with TLS 1.2+, terminated by Cloudflare.
  • No public endpoints. No database and no internal service is reachable from the Internet, and no admin surface is exposed without authentication.
  • Isolated per-service databases. Each service owns its own database with its own credentials — ten isolated Postgres/TimescaleDB databases in total, so one compromised credential never opens the whole platform.
  • Secrets management. Secrets are stored in git only as encrypted SealedSecrets, decrypted exclusively inside the cluster. No plaintext secrets live in code or CI configuration.
  • Private supply chain. Source code lives in private git repositories and container images in a private registry.

5. Secure development and change management

  • Container images are built by CI and referenced by immutable commit-SHA tags — a deployed image is traceable to the exact commit that produced it.
  • Deployment is GitOps: the desired state is declared in git and applied by ArgoCD. Promotion to production is human-gated — no ad-hoc changes are made to production outside this flow.
  • Dependencies are pinned through lockfiles, so builds are reproducible and upgrades are explicit, reviewable changes.

6. Vulnerability and patch management

  • Critical vulnerabilities in deployed components are patched within 72 hours of a fix becoming available.
  • High-severity vulnerabilities are patched within 14 days.
  • Base container images are refreshed at least monthly to pick up upstream security fixes.

7. Logging and monitoring

  • Logs from all services are centralized (Grafana Loki) and retained for 30 days.
  • Logs exclude secrets, authentication tokens, and customer data payloads by design — they carry operational metadata, not customer content.

8. Incident response

Security incidents follow a six-step process:

  • 1. Detect and triage — confirm the incident, assess scope and severity.
  • 2. Contain — revoke affected credentials and tokens, isolate affected workloads, block malicious traffic at the tunnel.
  • 3. Notify — where a personal-data breach requires it by law, affected customers and authorities are notified within 72 hours.
  • 4. Eradicate and recover — remove the root cause, restore from backups where needed, rotate secrets.
  • 5. Post-mortem — a written post-incident review within 5 business days, including what will change to prevent recurrence.
  • 6. Preserve evidence — logs and artifacts relevant to the incident are preserved throughout the process.

9. Data retention and deletion

  • On account disconnect, termination, or written request, customer data other than Amazon Ads history is deleted from live databases within 30 days.
  • Amazon Ads history — the advertising metrics and catalog history in the time-series store and the raw stream archive, partitioned per advertiser and marketplace, and its performance archive, partitioned per advertiser account and profile — is kept indefinitely for every activated profile, so that a customer can compare a period with the same period in earlier years. A disconnect, a profile deletion or termination does not delete it. On a written request to support@selltics.net, it is deleted from the live databases and from the customer's archive partitions within 30 days. Archive records that cannot be attributed to an advertiser and marketplace, and failed deliveries, are kept at most 21 days.
  • While at least one profile of an advertiser account is activated, the performance records of every profile of that account are archived, the never-activated profiles included; those are stored only, not shown and not used by any feature. Deleting a profile stops collection for it, and deleting the last activated profile of the account stops collection for the account. The archived records of never-activated profiles are deleted 7 days after the last activated profile of the advertiser account is deleted, unless a profile of that account is activated again within those 7 days. A written request for a profile that removes the last activated profile of its advertiser account also deletes the archived records of the account's never-activated profiles; the history of the account's other activated profiles is kept.
  • Amazon Selling Partner data differs: order data is read from Amazon on each request and is not kept as a history, and a Selling Partner disconnect deletes the authorization token immediately.
  • AI audit records — prompts and tool results kept for billing and abuse review — are retained for 30 days, then pruned.
  • Backups are nightly logical dumps of the ten service databases, kept on a 14-day rotation. The time-series advertising-metrics store is backed up weekly on a 28-day rotation, with its raw metric events additionally archived to offsite object storage continuously. Each rotation runs after a successful dump and removes the dumps older than its window, so while the dumps succeed, deleted data leaves the nightly dumps at most 16 days and the weekly dumps at most 35 days after the dump that holds it was taken. Full dump copies are currently single-region.
  • Payment records are kept as accounting records for as long as accounting and tax law requires; the invoice for each top-up is issued by Paddle, the merchant of record. The raw webhook body Paddle sends to confirm a payment is erased 90 days after receipt, leaving only the record that the event was received.
  • Centralized logs are retained for 30 days (Section 7).
  • An account whose email address is not confirmed within 7 days of sign-up is deleted, with its consent record.
  • Session and trusted-device records are deleted 30 days after they expire or are revoked.
  • The email delivery log (masked recipient and its hash, never a message body) is kept 30 days.
  • Security audit events are kept 365 days.
  • Two-factor data — the encrypted secret and the recovery codes — is deleted when two-factor authentication is turned off or reset by support.
  • Consent records are kept for 3 years after account deletion as evidence of acceptance and removed on request after that; nothing deletes them automatically.

10. Policy review

This policy is reviewed at least once a year, after every security incident, and after significant architecture changes. The current version is always published at this page; it is effective as of October 23, 2026. Questions: support@selltics.net.