1fb7266469
- Introduced Aggregator.sol for Chainlink-compatible oracle functionality, including round-based updates and access control. - Added OracleWithCCIP.sol to extend Aggregator with CCIP cross-chain messaging capabilities. - Created .gitmodules to include OpenZeppelin contracts as a submodule. - Developed a comprehensive deployment guide in NEXT_STEPS_COMPLETE_GUIDE.md for Phase 2 and smart contract deployment. - Implemented Vite configuration for the orchestration portal, supporting both Vue and React frameworks. - Added server-side logic for the Multi-Cloud Orchestration Portal, including API endpoints for environment management and monitoring. - Created scripts for resource import and usage validation across non-US regions. - Added tests for CCIP error handling and integration to ensure robust functionality. - Included various new files and directories for the orchestration portal and deployment scripts.
183 lines
3.6 KiB
Markdown
183 lines
3.6 KiB
Markdown
# Security Documentation
|
|
|
|
## Security Overview
|
|
|
|
The DeFi Oracle Meta Mainnet implements multiple layers of security to protect the network and its users.
|
|
|
|
## Key Management
|
|
|
|
### Validator Keys
|
|
|
|
- Stored in Azure Key Vault
|
|
- Never stored on disk
|
|
- Rotated every 90 days
|
|
- Access restricted to validators only
|
|
|
|
### Oracle Keys
|
|
|
|
- Stored in Azure Key Vault
|
|
- Used via EthSigner
|
|
- Rotated every 90 days
|
|
- Access restricted to oracle publisher service
|
|
|
|
### Key Rotation
|
|
|
|
1. Generate new keys
|
|
2. Update Key Vault
|
|
3. Update node configurations
|
|
4. Restart nodes
|
|
5. Verify new keys are working
|
|
6. Remove old keys after verification
|
|
|
|
## Network Security
|
|
|
|
### Network Segmentation
|
|
|
|
- **Validators**: Private subnets, no public IPs
|
|
- **Sentries**: Public subnets, P2P access only
|
|
- **RPC Nodes**: DMZ subnet, HTTPS only
|
|
|
|
### Firewall Rules
|
|
|
|
- **Validators**: Internal communication only
|
|
- **Sentries**: P2P (30303) and internal communication
|
|
- **RPC Nodes**: HTTPS (443) and internal communication
|
|
|
|
### TLS/SSL
|
|
|
|
- TLS 1.2+ for all HTTPS connections
|
|
- mTLS for internal communication
|
|
- Certificate rotation every 90 days
|
|
|
|
## Access Control
|
|
|
|
### Node Permissioning
|
|
|
|
- Static node allowlists
|
|
- Prevents unauthorized nodes from joining
|
|
- Updated via configuration files
|
|
|
|
### Account Permissioning
|
|
|
|
- Account allowlists for RPC methods
|
|
- Prevents unauthorized transactions
|
|
- Updated via configuration files
|
|
|
|
### API Gateway
|
|
|
|
- Rate limiting per IP
|
|
- API key authentication (optional)
|
|
- Method allowlists
|
|
- CORS configuration
|
|
|
|
## Security Monitoring
|
|
|
|
### Logging
|
|
|
|
- All node operations logged
|
|
- Structured logging (JSON)
|
|
- Log aggregation (Loki)
|
|
- Log retention (30 days)
|
|
|
|
### Monitoring
|
|
|
|
- Prometheus metrics
|
|
- Alert rules for security events
|
|
- Grafana dashboards
|
|
- Alertmanager notifications
|
|
|
|
### Incident Response
|
|
|
|
- Security incident playbook
|
|
- Incident response team
|
|
- Escalation procedures
|
|
- Post-incident reviews
|
|
|
|
## Vulnerability Management
|
|
|
|
### Regular Audits
|
|
|
|
- Code audits quarterly
|
|
- Security audits annually
|
|
- Penetration testing annually
|
|
- Dependency updates monthly
|
|
|
|
### Patch Management
|
|
|
|
- Security patches applied within 24 hours
|
|
- Regular updates for dependencies
|
|
- Node software updates quarterly
|
|
- Emergency patches as needed
|
|
|
|
## Compliance
|
|
|
|
### Data Protection
|
|
|
|
- No personal data stored on-chain
|
|
- Privacy by design
|
|
- Data retention policies
|
|
- GDPR compliance (if applicable)
|
|
|
|
### Access Logging
|
|
|
|
- All RPC requests logged
|
|
- Access logs retained for 90 days
|
|
- Audit trails for admin operations
|
|
- Compliance reporting
|
|
|
|
## Security Best Practices
|
|
|
|
### For Operators
|
|
|
|
1. Use strong passwords
|
|
2. Enable multi-factor authentication
|
|
3. Rotate keys regularly
|
|
4. Monitor security alerts
|
|
5. Keep software updated
|
|
|
|
### For Developers
|
|
|
|
1. Follow secure coding practices
|
|
2. Use dependency scanning
|
|
3. Perform code reviews
|
|
4. Test security controls
|
|
5. Document security assumptions
|
|
|
|
### For Users
|
|
|
|
1. Verify contract addresses
|
|
2. Use trusted RPC endpoints
|
|
3. Check transaction details
|
|
4. Monitor account activity
|
|
5. Report suspicious activity
|
|
|
|
## Security Incidents
|
|
|
|
### Reporting
|
|
|
|
- Report security issues to security@d-bis.org
|
|
- Include detailed information
|
|
- Do not disclose publicly until fixed
|
|
|
|
### Response
|
|
|
|
1. Acknowledge receipt
|
|
2. Assess severity
|
|
3. Develop mitigation
|
|
4. Deploy fix
|
|
5. Notify users
|
|
6. Post-incident review
|
|
|
|
## Security Contacts
|
|
|
|
- **Security Team**: security@d-bis.org
|
|
- **Emergency**: +1-XXX-XXX-XXXX
|
|
- **PGP Key**: [Link to PGP key]
|
|
|
|
## Security Resources
|
|
|
|
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
|
|
- [Ethereum Security](https://ethereum.org/en/developers/docs/security/)
|
|
- [Besu Security](https://besu.hyperledger.org/en/stable/)
|
|
|