Security Best Practices

Alactic AGI handles sensitive document processing workloads. This guide covers security best practices for protecting your deployment, data, and access credentials.

Deployment Key Security

Understanding Deployment Keys

Your deployment access key (ak-xxxxx...) is the master credential for your Alactic AGI instance:

What it controls:

• Dashboard login access
• API authentication
• All document processing operations
• Settings modifications

Key characteristics:

• 40 alphanumeric characters
• Generated once during deployment
• Cannot be changed or rotated
• Stored in Azure Key Vault
• Required for all authenticated operations

Protecting Your Deployment Key

Critical: Treat deployment key like a password

DO:

• Store in password manager (1Password, LastPass, Bitwarden)
• Store in Azure Key Vault (already done automatically)
• Use environment variables in scripts/code
• Restrict access to key vault to authorized personnel only
• Use secrets management in CI/CD pipelines
• Document key location for team (securely)

DON'T:

• Commit key to git repositories
• Share key via email or chat (use secure sharing tools)
• Store key in plain text files
• Hardcode key in application source code
• Share key publicly (Stack Overflow, forums)
• Include key in screenshots or documentation

Secure Key Retrieval

From Azure Key Vault (Recommended):

# Get key using Azure CLI (requires Azure authentication)
az keyvault secret show \
  --vault-name alactic-kv-xxxxx \
  --name deployment-key \
  --query value -o tsv

From VM .env file (requires SSH access):

# SSH into VM first
ssh -i ~/.ssh/id_rsa alacticadmin@<vm-ip>

# View key (requires sudo)
sudo grep DEPLOYMENT_KEY /opt/alactic-agi/.env

From Dashboard Settings:

• Login to dashboard
• Go to Settings → Deployment Information
• Key displayed partially masked: ak-abc...xyz
• Click "Copy Full Key" (requires current session authentication)

Key Storage for Teams

For small teams (2-5 people):

Use shared password manager:

1. Create shared vault in 1Password/LastPass
2. Store deployment key in vault
3. Grant access to team members
4. Revoke access when team members leave

For larger teams (5+ people):

Use Azure Key Vault with RBAC:

1. Key already in Key Vault (alactic-kv-xxxxx)
2. Create Azure AD security group for team
3. Grant group "Key Vault Secrets User" role
4. Team members retrieve key via Azure CLI or Portal
5. Audit access via Azure Monitor logs

For automated systems:

Use Managed Identity (Azure resources) or Service Principal:

# Create service principal for CI/CD
az ad sp create-for-rbac --name "AlacticCICD" \
  --role "Key Vault Secrets User" \
  --scopes /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/alactic-kv-xxxxx

# Returns:
# {
#   "appId": "...",
#   "password": "...",
#   "tenant": "..."
# }

# Use in CI/CD to retrieve key
az login --service-principal -u <appId> -p <password> --tenant <tenant>
az keyvault secret show --vault-name alactic-kv-xxxxx --name deployment-key

What to Do If Key is Compromised

If deployment key is exposed (committed to git, shared publicly, etc.):

Immediate actions:

1. Restrict Network Access

   • Go to Azure Portal → Network Security Group
   • Add rule to block all inbound traffic temporarily
   • Or whitelist only your IP addresses

2. Monitor for Unauthorized Access

   • Check dashboard Usage Statistics for unexpected activity
   • Review processing history for unknown documents
   • Check Azure Cost Management for cost spikes

3. Redeploy (Only Option to Change Key)

   • Deployment key cannot be changed once created
   • Must redeploy to get new key
   • Export/backup data before redeploying
   • See Changing Deployment Key section

Long-term prevention:

• Use .gitignore to prevent committing secrets
• Enable git commit scanning (GitHub secret scanning, GitGuardian)
• Implement secret scanning in CI/CD pipelines
• Regular security audits

Changing Deployment Key

Important: Deployment keys are immutable and cannot be rotated.

To get a new key, you must redeploy:

1. Backup existing data

   # Export Cosmos DB data
   # Export any uploaded documents from storage
   # Document your configuration

2. Delete current deployment

   • Go to Azure Portal → Resource Groups
   • Delete resource group (or individual resources)

3. Redeploy from marketplace

   • Follow Marketplace Deployment guide
   • New deployment generates new key

4. Restore data and reconfigure

   • Import backed-up data
   • Update any applications using the API with new key

Downtime: Plan for 30-60 minutes

Network Security

Network Security Group (NSG) Configuration

By default, Alactic AGI allows all inbound HTTPS traffic. Restrict access for better security.

View Current Rules:

1. Go to Azure Portal → Resource Groups
2. Click Network Security Group resource
3. Click "Inbound security rules"

Default configuration:

Priority | Name       | Port | Source    | Action
---------|------------|------|-----------|-------
100      | AllowHTTPS | 443  | Any       | Allow
200      | AllowSSH   | 22   | Any       | Allow
65000    | DenyAll    | Any  | Any       | Deny

Restrict Dashboard Access by IP

For corporate deployments:

Whitelist only your office IP addresses:

1. Go to NSG → Inbound security rules
2. Click "AllowHTTPS" rule
3. Change "Source" from "Any" to "IP Addresses"
4. Enter allowed IP addresses (comma-separated):

   203.0.113.0/24, 198.51.100.50, 192.0.2.100

5. Save changes
6. Test access from allowed and denied IPs

For remote teams:

Use Azure Virtual Network peering or VPN:

1. Create Azure Virtual Network with VPN Gateway
2. Connect team members via VPN
3. Restrict NSG to allow only VPN subnet
4. All access goes through secure VPN tunnel

For dynamic IPs (remote workers):

Use Azure Bastion or VPN instead of IP whitelisting:

• Azure Bastion provides secure RDP/SSH without exposing ports
• VPN ensures all traffic encrypted and authenticated

Disable SSH Access (Production Recommended)

After initial setup, disable SSH for production:

1. Go to NSG → Inbound security rules
2. Click "AllowSSH" rule
3. Change "Action" to "Deny"
4. Or delete the rule entirely

Re-enable if needed:

• Create new rule allowing SSH from your IP only
• Use Azure Bastion for emergency access

HTTPS/TLS Configuration

Default: Self-signed certificate (sufficient for testing)

For production: Use valid SSL certificate

Option 1: Let's Encrypt (Free)

SSH into VM and run:

# Install certbot
sudo apt-get update
sudo apt-get install -y certbot python3-certbot-nginx

# Get certificate (requires domain name pointing to VM)
sudo certbot --nginx -d yourdomain.com

# Auto-renewal already configured
sudo systemctl status certbot.timer

Option 2: Azure Front Door with Managed Certificate

1. Create Azure Front Door resource
2. Configure backend pool pointing to VM
3. Azure provides free managed certificate
4. Traffic encrypted end-to-end

Option 3: Azure Application Gateway with SSL Termination

1. Deploy Application Gateway
2. Upload your SSL certificate
3. Configure backend pool with VM
4. SSL terminated at gateway, re-encrypted to backend

Firewall Rules

Outbound connectivity requirements:

Alactic AGI needs outbound access to:

Destination	Port	Purpose
Azure OpenAI (*.openai.azure.com)	443	Model API calls
Azure Cosmos DB (*.documents.azure.com)	443	Database access
Azure Storage (*.blob.core.windows.net)	443	File storage
Azure Key Vault (*.vault.azure.net)	443	Secret retrieval
pypi.org, packages.microsoft.com	443	Package updates

If using outbound firewall rules:

Allow these destinations in your firewall/NSG outbound rules.

Data Security

Data at Rest Encryption

Automatically enabled:

• Virtual Machine Disk: Azure Storage Service Encryption (AES-256)
• Cosmos DB: Encrypted with Microsoft-managed keys
• Azure Storage: Encrypted with Microsoft-managed keys
• Azure Key Vault: FIPS 140-2 Level 2 validated HSMs

No configuration required - encryption enabled by default.

For customer-managed keys (Enterprise only):

1. Create Azure Key Vault
2. Generate encryption key in Key Vault
3. Configure Cosmos DB to use customer-managed key:

   az cosmosdb update \
     --name <account-name> \
     --resource-group <rg> \
     --key-uri <key-vault-key-uri>

4. Configure Storage Account similarly

Benefits:

• Full control over encryption keys
• Key rotation on your schedule
• Revoke access instantly by disabling key

Data in Transit Encryption

Automatically enabled:

• Dashboard ↔ Browser: HTTPS/TLS 1.2+
• VM ↔ Azure OpenAI: HTTPS/TLS 1.2+
• VM ↔ Cosmos DB: HTTPS/TLS 1.2+
• VM ↔ Azure Storage: HTTPS/TLS 1.2+

Verify TLS configuration:

# Check nginx TLS config
sudo grep ssl_protocols /etc/nginx/sites-available/alactic

# Should show:
ssl_protocols TLSv1.2 TLSv1.3;

Document Storage Security

Uploaded PDFs storage location:

PDFs stored in Azure Blob Storage container:

• Container name: documents
• Access: Private (no anonymous access)
• Accessed only via deployment key authentication

Verify container is private:

1. Go to Azure Portal → Storage Account
2. Click "Containers"
3. Click "documents" container
4. Check "Public access level": Private
5. If not private, change to Private immediately

Document retention:

By default, documents retained indefinitely.

To configure auto-deletion:

# Create lifecycle management rule
az storage account management-policy create \
  --account-name <storage-account> \
  --policy '{
    "rules": [{
      "name": "DeleteOldDocuments",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "delete": {
              "daysAfterModificationGreaterThan": 90
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["documents/"]
        }
      }
    }]
  }'

Effect: Automatically deletes documents older than 90 days.

Database Security

Cosmos DB security:

• Authentication: Account keys stored in Key Vault
• Authorization: All access via VM's managed identity or keys
• Network: Can restrict to VM's virtual network only

Restrict Cosmos DB to VM only:

1. Go to Azure Portal → Cosmos DB account
2. Click "Firewall and virtual networks"
3. Select "Selected networks"
4. Add VM's virtual network and subnet
5. Remove "Allow access from Azure portal" for maximum security
6. Save changes

Effect: Cosmos DB accessible only from VM, not from internet.

Access Control and Auditing

Azure RBAC for Management

Control who can manage deployment:

Principle of least privilege:

• Most users: No Azure access needed (just deployment key for dashboard)
• Operators: Reader role on resource group
• Administrators: Contributor role on resource group
• Security team: Security Reader role across subscription

Assign roles:

1. Go to Azure Portal → Resource Groups
2. Click "Access control (IAM)"
3. Click "Add role assignment"
4. Select role (Reader, Contributor, etc.)
5. Select user or group
6. Save assignment

Common roles:

Role	Can Do	Use For
Reader	View resources, can't modify	Auditors, support staff
Contributor	Modify resources, can't grant access	DevOps, administrators
Key Vault Secrets User	Read secrets only	Developers, CI/CD
Owner	Full control including access management	Single admin only

Audit Logging

Enable Azure Monitor logs:

1. Go to Azure Portal → Resource Groups
2. Click "Activity log" in left sidebar
3. Click "Export Activity Logs"
4. Create Log Analytics workspace
5. Send logs to workspace
6. Set retention (e.g., 90 days)

What's logged:

• Resource creation/deletion/modification
• Access to Key Vault secrets
• NSG rule changes
• VM start/stop operations
• Deployment key retrievals

View logs:

// Query in Log Analytics
AzureActivity
| where ResourceGroup == "alactic-rg-xxxxx"
| where TimeGenerated > ago(7d)
| project TimeGenerated, Caller, OperationName, ResourceId
| order by TimeGenerated desc

VM Access Auditing

Enable SSH logging:

# Edit SSH config
sudo nano /etc/ssh/sshd_config

# Ensure these are set:
LogLevel INFO
# Or for verbose: LogLevel VERBOSE

# Restart SSH
sudo systemctl restart sshd

View SSH access logs:

# View recent SSH logins
sudo journalctl -u ssh -n 100

# View auth attempts
sudo cat /var/log/auth.log | grep sshd

Alert on unauthorized access attempts:

Configure Azure Monitor to alert on failed SSH attempts.

Compliance and Certifications

Azure Compliance

Alactic AGI leverages Azure's compliance certifications:

Supported compliance frameworks:

• SOC 1, SOC 2, SOC 3
• ISO 27001, ISO 27018, ISO 27701
• GDPR (EU data protection)
• HIPAA (healthcare)
• FedRAMP (US government)
• PCI DSS (payment card industry)

Verify compliance: Azure Compliance Offerings

Data Residency

Control where data is stored:

Data residency determined by Azure region selected during deployment.

GDPR compliance:

• Deploy in EU regions (West Europe, North Europe, France Central, etc.)
• Data stays within EU
• No cross-border data transfer

For strict data residency:

1. Deploy in required region
2. Disable Cosmos DB multi-region replication
3. Use customer-managed encryption keys in same region
4. Restrict NSG to region-specific IP ranges

Data Processing Agreement (DPA)

For enterprise customers:

Microsoft provides Data Processing Addendum covering:

• GDPR Article 28 requirements
• Subprocessor list
• Data subject rights
• Breach notification

Access DPA: Microsoft Online Services DPA

Security Monitoring

Set Up Security Alerts

Recommended alerts:

1. Unusual API activity

   • Alert if >1000 API calls in 1 hour
   • May indicate compromised key

2. Failed authentication attempts

   • Alert if >10 failed logins in 5 minutes
   • May indicate brute force attack

3. Unexpected resource modifications

   • Alert on NSG rule changes
   • Alert on VM configuration changes

4. High costs

   • Alert if daily cost >$50 (adjust based on plan)
   • May indicate unauthorized usage

Configure alerts in Azure Portal:

1. Go to Azure Monitor → Alerts
2. Click "New alert rule"
3. Select resource
4. Define condition (e.g., HTTP 401 errors > 10)
5. Add action group (email, SMS, webhook)
6. Enable alert

Security Checklist

Use this checklist to audit security monthly:

• ☐ Deployment key stored securely (password manager or Key Vault)
• ☐ NSG rules restrict access to known IPs only
• ☐ SSH access disabled or restricted
• ☐ Valid SSL certificate installed (not self-signed)
• ☐ Cosmos DB restricted to VM's virtual network
• ☐ Storage container access is Private
• ☐ Azure RBAC roles assigned per least privilege
• ☐ Activity logging enabled and retained 90+ days
• ☐ Security alerts configured for anomalies
• ☐ Team members who left have Azure access revoked
• ☐ VM operating system updates applied monthly
• ☐ Application dependencies updated (pip list --outdated)

Security Incident Response

If you suspect security incident:

1. Isolate deployment

   • Block all NSG inbound traffic immediately
   • Or shut down VM

2. Assess impact

   • Check usage statistics for unauthorized processing
   • Review activity logs for suspicious access
   • Check cost management for unexpected charges

3. Collect evidence

   • Export activity logs
   • Take VM disk snapshot
   • Document timeline

4. Remediate

   • If key compromised: redeploy with new key
   • If VM compromised: redeploy VM
   • If data exfiltrated: notify affected parties

5. Prevent recurrence

   • Implement missing controls from security checklist
   • Update incident response procedures
   • Train team on security best practices

Contact Alactic Security Team:

• Email: support@alacticai.com
• Include: Deployment ID, incident summary, impact assessment
• Enterprise customers: 4-hour response SLA

Related Documentation

• Deployment Key Guide
• Compliance and Certifications
• Disaster Recovery
• Monitoring Guide