What is the security guidance for Myota?

By adhering to these practices, you can effectively protect your Myota object storage secrets from unauthorized access and minimize the potential for breaches or misconfigurations.

Myota uses key shards and object storage secrets, the difference between Myota's key shards and object storage secrets lies in their function and purpose within the Myota platform:

Key Shards

Purpose: Key shards are part of Myota’s encryption and decryption process.
Function: Myota splits encryption keys into multiple fragments (shards) and distributes them across different locations. This process ensures:
- No single entity has access to the complete encryption key.
- Unauthorized access is prevented even if one shard is compromised.
Role in Security: Key shards are crucial to Myota’s zero-knowledge encryption model, ensuring that neither Myota nor any third party can reconstruct the encryption key to access your data.

Object Storage Secrets

Purpose: Object storage secrets manage access control and authentication for storing and retrieving fragmented data from object storage.
Function: These secrets are used to:
- Authenticate with external or integrated object storage systems (e.g., AWS S3, Azure Blob).
- Manage how Myota communicates with storage providers to store the "shredded and spread" data fragments securely.
Role in Security: Object storage secrets ensure that only authorized systems or processes can access the storage buckets, maintaining the integrity and confidentiality of the fragmented data.

Feature	Key Shards	Object Storage Secrets
Primary Purpose	Encrypt and decrypt data	Authenticate and manage access to object storage
Functionality	Splits and distributes encryption keys	Handles secure storage of data fragments in object storage
Role in Security	Ensures zero-knowledge encryption	Controls access to object storage systems
Usage Scope	Data fragmentation encryption processes	Storage managements

How They Work Together

Key shards secure the encryption keys, ensuring that only authorized users can decrypt data.
Object storage secrets secure the storage process, ensuring that data fragments are safely stored and retrieved from external storage systems.

These components together form Myota’s secure, decentralized, and immutable data protection architecture.

Protecting Myota object storage secrets
Protecting Myota object storage secrets (such as API keys, access keys, and credentials) is crucial to prevent unauthorized access and maintain data security. Here are best practices for securing these secrets:

1. Use Centralized Secret Management Systems

Dedicated Secret Managers: Use tools like AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault to securely store and manage secrets.

Automated Rotation: Configure automated secret rotation to reduce the impact of leaked or compromised secrets.

2. Restrict Access to Secrets

Principle of Least Privilege: Grant access only to entities (users, applications, or services) that require the secret to perform their function.
IAM Policies: Apply strict IAM policies to control who can read or modify secrets.

Environment Segregation: Store secrets separately for development, staging, and production environments to minimize exposure.

3. Encrypt Secrets

Encryption at Rest: Store secrets in an encrypted format using strong encryption algorithms (e.g., AES-256).
Encryption in Transit: Use HTTPS or other secure protocols to transmit secrets to prevent interception.

Hardware Security Modules (HSMs): For sensitive operations, manage encryption keys within HSMs to ensure strong key security.

4. Avoid Hardcoding Secrets

Environment Variables: Store secrets in environment variables rather than hardcoding them into application code.

Configuration Files: If using configuration files, ensure they are encrypted and excluded from version control systems like Git.

5. Rotate Secrets Regularly

Scheduled Rotation: Implement regular secret rotation to reduce the exposure of long-lived credentials.

Immediate Rotation on Compromise: Rotate keys or credentials immediately if you suspect they are compromised.

6. Use Short-Lived Credentials

Temporary Tokens: Prefer temporary credentials generated by services like AWS STS or Azure Managed Identities over static keys.

Session Limits: Limit the lifespan of access tokens to minimize exposure risk.

7. Monitor and Audit Secret Access

Access Logs: Use logging and monitoring tools to track who accessed a secret and when.

Alerts on Anomalies: Configure alerts for unusual access patterns, such as secrets accessed from unexpected locations or by unauthorized entities.

8. Secure Secrets in CI/CD Pipelines

Secure Vaults: Integrate secret management tools with CI/CD pipelines to securely inject secrets during deployment.

Mask Secrets: Mask secrets in CI/CD logs and outputs to prevent accidental exposure.

9. Minimize Secret Usage

Instance Profiles/Managed Identities: Use instance profiles (e.g., AWS IAM roles, Azure Managed Identities) to assign permissions directly to workloads without embedding secrets.

Policy-Based Access: Use policies to grant and revoke access dynamically without hardcoded keys.

10. Regularly Audit and Remove Unused Secrets

Inventory Secrets: Maintain a centralized inventory of all secrets and regularly audit for unused or outdated ones.

Delete Obsolete Secrets: Remove secrets that are no longer required to reduce the attack surface.

11. Educate Teams

Developer Training: Train developers and administrators on secure handling practices for secrets.
Security Policies: Establish clear guidelines for managing, using, and securing secrets.

By adhering to these practices, you can effectively protect your Myota object storage secrets from unauthorized access and minimize the potential for breaches or misconfigurations