security
Security Considerations
Section titled “Security Considerations”Ongoing security concerns and mitigations for the project.
Threat Model
Section titled “Threat Model”Assets
Section titled “Assets”- Vault content - User knowledge bases
- Credentials - SSO tokens, session data
- Infrastructure - Servers, containers
Threat Actors
Section titled “Threat Actors”- Unauthorized external - Internet attackers
- Unauthorized internal - Employees without access
- Authorized but malicious - Insider threats
Security Layers
Section titled “Security Layers”Layer 1: VNC Gateway
Section titled “Layer 1: VNC Gateway”| Concern | Mitigation |
|---|---|
| Session hijacking | SSO with MFA, session timeouts |
| VNC protocol exposure | HTTPS/WSS only, no raw VNC |
| Container escape | Hardened base images, no root |
Layer 2: CRDT Sync
Section titled “Layer 2: CRDT Sync”| Concern | Mitigation |
|---|---|
| Data interception | TLS for WebSocket transport |
| State file tampering | Signed CRDT states (future) |
| DoS via large updates | Size limits, rate limiting |
Layer 3: Mount Orchestration
Section titled “Layer 3: Mount Orchestration”| Concern | Mitigation |
|---|---|
| Unauthorized vault access | JWT validation, group checking |
| Privilege escalation | Vault-level RBAC, no file-level |
| Audit evasion | Immutable audit logs |
Authentication & Authorization
Section titled “Authentication & Authorization”SSO Integration
Section titled “SSO Integration”- Use OIDC/SAML with enterprise IdP
- MFA required for sensitive vaults
- Short session timeouts
RBAC Model
Section titled “RBAC Model”User → IdP Groups → Vault Permissions → Mount ControlNo file-level permissions by design. See Decision-002.
Data Protection
Section titled “Data Protection”At Rest
Section titled “At Rest”- Vault files on encrypted storage
- CRDT state files alongside content
- Secrets in secure vault (HashiCorp Vault?)
In Transit
Section titled “In Transit”- TLS 1.3 for all connections
- WebSocket over HTTPS (WSS)
- No plaintext protocols
Backups
Section titled “Backups”- Regular vault backups
- Point-in-time recovery via CRDT history
- Backup encryption
Plugin Security
Section titled “Plugin Security”Obsidian Plugins
Section titled “Obsidian Plugins”| Risk | Mitigation |
|---|---|
| Malicious plugins | Curated plugin list, no auto-update |
| Plugin network access | Firewall rules per plugin (ideal) |
| Data exfiltration | Network monitoring, DLP |
Plugin Management
Section titled “Plugin Management”Options:
- Whitelist approach - Only approved plugins
- Block GitHub - No plugin downloads, manual install
- Review process - Audit before approval
See [Obsidian Setup for Corporate](cyberbase vault) for detailed approach.
Audit Logging
Section titled “Audit Logging”Events to Log
Section titled “Events to Log”- Vault access (mount)
- File operations (create, modify, delete)
- Authentication events
- Failed access attempts
Log Format
Section titled “Log Format”{ "timestamp": "2024-12-20T00:00:00Z", "event": "vault_access", "userId": "user@example.com", "vaultId": "engineering", "action": "mount", "result": "success", "clientIp": "10.0.0.1"}Log Storage
Section titled “Log Storage”- Structured JSON logs
- Ship to SIEM (Splunk, Elastic, etc.)
- Retention per compliance requirements
Compliance Considerations
Section titled “Compliance Considerations”- Access controls (RBAC)
- Audit logging
- Encryption in transit/at rest
- Incident response
- Data minimization
- Right to deletion (purge from CRDT?)
- Data export capability
HIPAA (if applicable)
Section titled “HIPAA (if applicable)”- BAA with cloud providers
- Access logging
- Encryption requirements
Open Questions
Section titled “Open Questions”- CRDT state signing - How to verify state integrity?
- Binary file encryption - Encrypt in MinIO?
- Key management - Where to store encryption keys?
- Plugin isolation - Can we sandbox plugins?