Deployment Best Practices
Fystack enforces strict deployment security controls to protect production infrastructure and sensitive cryptographic material. This document outlines our core deployment security principles: network isolation, access control, and endpoint protection.
1. Private Network Deployment with VPN Access
All Fystack production infrastructure is deployed within private networks with mandatory VPN access, ensuring that critical services are never directly exposed to the public internet.
Network Architecture
Component | Network Configuration |
|---|---|
Application Servers | Deployed in private subnets with no public IP addresses |
Database Servers | Isolated in dedicated database subnets, accessible only from application tier |
MPC Nodes | Deployed in highly restricted private network with peer-to-peer VPN mesh |
Admin Access | VPN required for all administrative operations and deployments |
Public Internet | Only load balancers and API gateways have public endpoints |
VPN Access Requirements
All personnel accessing production infrastructure must authenticate through VPN with the following controls:
- Multi-factor authentication (MFA): Hardware security keys or authenticator apps required
- Device compliance: Only managed devices with full disk encryption and endpoint protection
- IP allowlisting: VPN access restricted to authorized IP ranges
- Session monitoring: All VPN sessions logged and monitored for anomalies
- Automatic timeout: VPN sessions expire after 8 hours of inactivity
- Certificate-based authentication: Client certificates required in addition to credentials
Network Segmentation
Network Tier | Access Control |
|---|---|
Public Zone | Load balancers, CDN, DDoS protection only |
DMZ Zone | API gateway, reverse proxies, WAF |
Application Zone | Application servers, accessible from DMZ and VPN only |
Data Zone | Databases, accessible from application zone only |
Secure Zone | MPC nodes, KMS, secret stores - highest restriction level |
2. Cloud IAM Roles for KMS and Secret Manager Access
Fystack uses Cloud IAM roles to enforce the principle of least privilege for access to Key Management Service (KMS) and Secret Manager. Only essential services and C-level executives have access to critical cryptographic material.
IAM Access Model
Resource | Who Has Access | Permission Level |
|---|---|---|
KMS Master Keys | CEO, CTO only | Full access (encrypt, decrypt, manage) |
Secret Manager | CEO, CTO only | Full access (read, write, delete) |
Application Services | API service, MPC nodes (via service account) | Read-only access to specific secrets |
Developers | No access | No permissions to production KMS or secrets |
DevOps Team | No direct access | Can deploy, but cannot read secret values |
Service Account Restrictions
Application services access KMS and Secret Manager through service accounts with tightly scoped permissions:
- Service-specific accounts: Each service has its own dedicated service account
- Minimum permissions: Only permissions required for specific operations
- Secret-level access control: Access granted per individual secret, not entire secret store
- Time-bound credentials: Service account tokens expire and rotate automatically
- Audit logging: All KMS and Secret Manager access logged to immutable audit trail
Access Control Policies
KMS Access Policy Example:
- CEO and CTO can manage KMS keys and view audit logs
- Application service accounts can only encrypt/decrypt with specific keys
- All key usage is logged with caller identity and timestamp
- Key deletion requires dual authorization from both CEO and CTO
- Key rotation is automated and monitored
Secret Manager Access Policy Example:
- CEO and CTO can create, read, update, and delete secrets
- Application services can only read secrets assigned to them
- Secret access is logged with service identity and IP address
- Secret versions are immutable and retained for audit purposes
- Secret rotation triggers automatic service updates
3. Endpoint Detection and Response (EDR)
Fystack deploys Endpoint Detection and Response (EDR) solutions such as CrowdStrike or Bitdefender as sidecars to detect and prevent infiltration attempts on all production systems.
EDR Deployment Architecture
Component | EDR Protection |
|---|---|
Container Sidecar | EDR agent deployed as sidecar container in every pod |
Process Monitoring | Real-time monitoring of all process executions and syscalls |
Network Traffic | Inspection of inbound and outbound network connections |
File Integrity | Detection of unauthorized file modifications |
Memory Scanning | Detection of memory-resident malware and code injection |
EDR Capabilities
Threat Detection:
- Behavioral analysis: Identifies anomalous process behavior and privilege escalation
- Signature-based detection: Blocks known malware and exploits
- Machine learning: Detects zero-day threats and advanced persistent threats (APTs)
- Lateral movement detection: Identifies unauthorized access attempts across systems
- Ransomware protection: Detects and blocks file encryption attempts
Response Actions:
- Automatic containment: Isolate compromised containers from network
- Process termination: Kill malicious processes automatically
- Forensic capture: Preserve memory and disk state for investigation
- Alert escalation: Immediate notification to security team
- Rollback capability: Restore from known-good container images
EDR Monitoring and Alerting
Alert Type | Response Action |
|---|---|
Critical Threat Detected | Automatic container isolation, immediate security team notification |
Suspicious Process Execution | Process killed, alert sent to security operations center |
Unauthorized Network Connection | Connection blocked, network traffic logged for analysis |
File Integrity Violation | Container redeployed from verified image, incident logged |
Memory Injection Detected | Process terminated, memory dump captured, CEO/CTO notified |
EDR Integration
- SIEM integration: EDR events forwarded to Security Information and Event Management system
- Incident response playbooks: Automated response workflows for common threat scenarios
- Threat intelligence feeds: Real-time updates on emerging threats and indicators of compromise
- Compliance reporting: Automated compliance reports for security audits
- Forensic analysis: Detailed telemetry for post-incident investigation
4. Summary
Fystack's deployment security strategy is built on three fundamental pillars:
- Private network isolation with VPN access ensures critical infrastructure is never directly exposed to the internet
- Strict IAM controls limit KMS and Secret Manager access to CEO and CTO only, with minimal service account permissions
- EDR sidecar deployment provides real-time threat detection and automated response across all production systems
These controls work together to create a defense-in-depth security posture that protects cryptographic keys, sensitive data, and production infrastructure from both external and internal threats.