This document collects the security questions client CISOs and CSOs raise when evaluating OKAXI. Answers reference international standards directly and reflect current production operating practice.
Data at rest is encrypted with AES-256 to the FIPS 197 standard. Encryption applies in three layers. The first layer is the cloud provider native disk encryption (LUKS or AWS EBS encryption). The second layer is database TDE (Transparent Data Encryption) on PostgreSQL and MongoDB. The third layer is field-level encryption with an envelope key for sensitive data such as password hashes, PII, and contract financial values.
Every connection from a client to a public endpoint runs TLS 1.3 with forward secrecy by default. TLS 1.2 is only accepted for specific legacy clients and TLS 1.0 or 1.1 is never accepted. The cipher suite whitelist covers AES-256-GCM and ChaCha20-Poly1305. Internal service-to-service traffic runs mTLS through a service mesh (Istio or Linkerd) with certificates rotating automatically every 24 hours.
OKAXI uses a dedicated KMS per environment (production, staging, development). The master key lives in an HSM (AWS CloudHSM, Azure Key Vault Premium, or on-premise Thales Luna). The data encryption key (DEK) is generated at runtime, wrapped by the master key, and only unwrapped inside process memory. Key rotation happens automatically every 90 days. Old keys are retained for 1 year for decrypt-only operations.
Yes. Enterprise clients bring their own HSM (Thales, Entrust, or an AWS CloudHSM cluster) and provide the master key over a secure channel. OKAXI only invokes wrap and unwrap operations through the KMS API and never touches raw key material. Clients can revoke the key at any moment. After revocation, OKAXI can no longer decrypt the data. This policy fits clients with strict data sovereignty requirements.
OKAXI applies deterministic encryption for fields that need search (email, tax_id) and randomised encryption for fields used only on read and write (salary, contract_value). Deterministic encryption yields the same ciphertext for the same plaintext, which enables equality search on the ciphertext. Randomised encryption yields different ciphertext each time, which provides stronger protection but cannot be searched. The pattern choice follows the threat model review.
OKAXI offers three isolation patterns per client contract. Pattern A is logical isolation: shared infrastructure, shared database, every row carries a tenant_id, and row-level security policies enforce separation. Pattern B is database-per-tenant: shared compute and isolated database, higher cost but stronger isolation. Pattern C is dedicated infrastructure: dedicated VPC, dedicated Kubernetes cluster, and dedicated hardware per contract. Pattern C fits banking, healthcare, and government clients.
Four layers of protection. First, the database query layer mandates a tenant_id filter, the library injects it into every query, and any bypass requires an explicit override with an audit log. Second, the API gateway extracts tenant_id from the JWT and rejects mismatched requests. Third, cache keys are prefixed with tenant_id so no cache slot is ever shared. Fourth, background jobs tag tenant_id into message metadata and consumers reject any cross-tenant job.
OKAXI uses a dedicated VPC per Pattern C tenant. Each VPC splits subnets into public (load balancer), private app (workload), and private data (database and cache). Security groups whitelist specific traffic between subnets. Private subnets carry no public IP. Egress flows through a NAT gateway with an FQDN whitelist. Cross-VPC traffic only goes through VPC peering with an explicit route and never through a default-route bridge.
OKAXI does not allow direct SSH into production instances. All access goes through a bastion host with two factors: a short-lived SSH key (4 hours) issued by HashiCorp Vault and an OTP (2FA). Sessions are fully recorded with asciinema and streamed to the SIEM. Sudo elevation requires chat-ops bot approval from a second engineer. Production access logs sit in audit storage for 7 years.
OKAXI applies zero-trust at three layers. Identity layer: every service authenticates through mTLS with a SPIFFE ID, no IP-based trust. Authorisation layer: every request decision flows through a central policy engine (OPA), with no assumption of a trusted network. Data layer: end-to-end encryption between services so the transit network is never trusted, even inside the VPC. Continuous verification is enforced through weekly audit log reviews.
OKAXI uses a managed WAF at the edge (AWS WAF or Cloudflare WAF) combined with an inline WAF (ModSecurity with OWASP CRS) at the Ingress layer. The rule set covers OWASP Top 10 protection (SQL injection, XSS, RCE), per-IP rate limit, country geo-block, and custom rules for business logic abuse. Clients can enable or disable rules per environment through the admin console. The false positive rate stays under 0.1 percent on production traffic.
OKAXI runs three layers of DDoS protection. The first layer is DNS-level through Cloudflare or AWS Shield Advanced with always-on TB per second absorption capacity. The second layer is edge rate limiting per source IP and per ASN. The third layer is application-level circuit breakers that cut traffic when error rate bursts. Anycast IP routing absorbs traffic globally.
OKAXI runs four scan layers on a regular cadence. SAST (Snyk, SonarQube) on every pull request and commit. Container scan on every image build through Trivy or Aqua. DAST (OWASP ZAP, Burp Suite) on the staging environment every night. Infrastructure scan (Tenable or Qualys) on production weekly. Critical CVEs are patched within 24 hours. High CVEs within 7 days. Medium within 30 days.
OKAXI maintains an on-call security team monitoring CVE feeds (NVD, vendor advisories) 24/7. When a zero-day is published, the team evaluates exposure within 2 hours. If there is impact, a hot patch or workaround (temporary WAF rule, feature flag to disable the component) deploys within 8 hours. The vendor patch is applied after testing within 24 to 48 hours. Communication to affected clients flows through email and an in-app banner.
OKAXI follows an incident response playbook aligned with NIST SP 800-61. Six phases: prepare, identify, contain, eradicate, recover, post-mortem. Severity 1 (confirmed data breach) escalates within 15 minutes, a war room activates, and a dedicated communication channel is opened. Customer notification follows the GDPR 72-hour clock. The internal post-mortem completes within 14 days with root cause analysis and action items. Lessons learned feed back into training and playbook updates.
OKAXI runs a three-tier backup strategy. Tier 1 (Database): continuous WAL streaming, point-in-time recovery, RPO 1 minute, RTO 30 minutes. Tier 2 (Application state): daily snapshot, cross-region replication, RPO 24 hours, RTO 4 hours. Tier 3 (Cold archive): monthly snapshot on Glacier or Coldline, RPO 30 days, RTO 24 hours. Backups are encrypted with AES-256 before leaving the production VPC.
OKAXI deploys a multi-region active-standby for enterprise clients. The primary region (Singapore) replicates data to the DR region (Tokyo) through database replication and Kafka cross-cluster mirroring. Failover RTO is 1 hour with RPO 5 minutes for hot data. Failover triggers through an automated runbook when the primary region misses several consecutive health checks. An annual DR exercise switches full traffic into the DR region to verify the procedure.
Yes. OKAXI runs three levels of restore drill. Daily: automated PIT recovery on a random database, integrity verified, no human needed. Monthly: full backup restore into an isolated environment, the application stack comes up green, and smoke tests pass. Quarterly: cross-region DR drill where traffic is switched, production-like load runs for 2 hours, and traffic is switched back. Every drill result lands in the compliance report.
OKAXI commits to notification within 72 hours per GDPR Article 33-34. When a breach is confirmed, three workstreams run in parallel. First, internal containment and investigation. Second, legal and compliance review of impact and notification requirements (GDPR, Vietnam PDPA, CCPA depending on customer region). Third, customer notification through the designated contact with the assessment scope, the remediation steps, and evidence preservation. Public disclosure depends on severity and regulatory mandate.
