CCC Object Storage Controls Catalog
This page renders the FINOS Common Cloud Controls Object Storage controls as a
Gemara ControlCatalog, including the shared CCC Core
controls this service catalog imports. Native Object Storage controls and
imported Core controls appear together with their assessment requirements.
For the companion catalogs, see the Capabilities Catalog and Threats Catalog.
Encryption
Encryption-related controls.
CCC.ObjStor.CN01Prevent Requests to Buckets or Objects with Untrusted KMS Keys
Prevent any requests to object storage buckets or objects using untrusted KMS keys to protect against unauthorized data encryption, or sensitive data decryption.
CCC.ObjStor.CN01.AR01When a request is made to read a bucket, the service MUST prevent any request using KMS keys not listed as trusted by the organization.
Applicability:
tlp-ambertlp-redCCC.ObjStor.CN01.AR02When a request is made to read an object, the service MUST prevent any request using KMS keys not listed as trusted by the organization.
Applicability:
tlp-ambertlp-redCCC.ObjStor.CN01.AR03When a request is made to write to a bucket, the service MUST prevent any request using KMS keys not listed as trusted by the organization.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.ObjStor.CN01.AR04When a request is made to write to an object, the service MUST prevent any request using KMS keys not listed as trusted by the organization.
Applicability:
tlp-cleartlp-greentlp-ambertlp-red
CCC.Core.THCCC.Core.TH01Access is Granted to Unauthorized UsersCCC.Core.TH06Data is Lost or Corrupted
CCMIAM-01IAM Policy and ProceduresIAM-03Identity Inventory (system identities and level of access)DSP-17Sensitive Data Protection
CCC.Core.CN01Encrypt Data for Transmissionimported
Imported from CCC.Core.CN
Ensure that all communications are encrypted in transit to protect data integrity and confidentiality.
CCC.Core.CN01.AR01When a port is exposed for non-SSH network traffic, all traffic MUST include a TLS handshake AND be encrypted using TLS 1.3 or higher.
Applicability:
tlp-greentlp-ambertlp-redRecommendation: Most cloud services enable TLS 1.3 by default. Where it is not already set, ensure that your services are configured or updated accordingly.
CCC.Core.CN01.AR02When a port is exposed for SSH network traffic, all traffic MUST include a SSH handshake AND be encrypted using SSHv2 or higher.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redRecommendation: Any time port 22 is exposed, ensure that it has a properly implemented SSH server with SSHv2 enabled and configured with strong ciphers.
CCC.Core.CN01.AR03When the service receives unencrypted traffic, then it MUST either block the request or automatically redirect it to the secure equivalent.
Applicability:
tlp-greentlp-ambertlp-redRecommendation: Review firewall, load balancer, and application configurations to ensure insecure protocols such as HTTP, FTP, and Telnet are not exposed. Where possible, implement automatic redirection to secure protocols such as HTTPS, SFTP, SSH, and regularly scan for protocol drift.
CCC.Core.CN01.AR07When a port is exposed, the service MUST ensure that the protocol and service officially assigned to that port number by the IANA Service Name and Transport Protocol Port Number Registry, and no other, is run on that port.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redRecommendation: Reference the IANA Service Name and Transport Protocol Port Number Registry for more information about correct protocol-to-port assignments. Avoid running non-standard services on well-known ports.
CCC.Core.CN01.AR08When a service transmits data using TLS, mutual TLS (mTLS) MUST be implemented to require both client and server certificate authentication for all connections.
Applicability:
tlp-ambertlp-redRecommendation: Configure mTLS for all endpoints that process or transmit sensitive data. Ensure both client and server certificates are validated and managed securely. Regularly review certificate authorities and automate certificate rotation where possible.
CCC.Core.ThreatsCCC.Core.TH02
CCMCEK-03Data Encryption (in transit and at rest)CEK-04Key Management (use strong encryption)IVS-03Network Security (monitor, encrypt, restrict)IVS-07Migration to Cloud Environments (encrypt when migrating servers)
CCC.Core.CN02Encrypt Data for Storageimported
Imported from CCC.Core.CN
Ensure that all data stored is encrypted at rest using strong encryption algorithms.
CCC.Core.CN02.AR01When data is stored, it MUST be encrypted using the latest industry-standard encryption methods.
Applicability:
tlp-greentlp-ambertlp-red
CCC.Core.ThreatsCCC.Core.TH01
CCMCEK-03Data Encryption (in transit and at rest)CEK-04Key Management (use strong encryption)UEM-08Storage Encryption (on managed endpoint devices)DSP-17
Data
Data storage, lifecycle, and durability capabilities.
CCC.ObjStor.CN03Prevent Bucket Deletion Through Irrevocable Bucket Retention Policy
Ensure that object storage bucket is not deleted after creation, and that the preventative measure cannot be unset.
CCC.ObjStor.CN03.AR01When an object storage bucket deletion is attempted, the bucket MUST be fully recoverable for a set time-frame after deletion is requested.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.ObjStor.CN03.AR02When an attempt is made to modify the retention policy for an object storage bucket, the service MUST prevent the policy from being modified.
Applicability:
tlp-cleartlp-greentlp-ambertlp-red
CCC.Core.THCCC.Core.TH06Data is Lost or Corrupted
CCMDSP-16Data Retention and DeletionDSP-17Sensitive Data Protection
CCC.ObjStor.CN04Objects have an Effective Retention Policy by Default
Ensure that all objects stored in the object storage system have a retention policy applied by default, preventing premature deletion or modification of objects.
CCC.ObjStor.CN04.AR01When an object is uploaded to the object storage system, the object MUST automatically receive a default retention policy that prevents premature deletion or modification.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.ObjStor.CN04.AR02When an attempt is made to delete or modify an object that is subject to an active retention policy, the service MUST prevent the action from being completed.
Applicability:
tlp-cleartlp-greentlp-ambertlp-red
CCC.Core.THCCC.Core.TH06Data is Lost or Corrupted
CCC.ObjStor.THCCC.ObjStor.TH01Data Exfiltration via Insecure Lifecycle Policies
CCMDSP-16Data Retention and DeletionDSP-17Sensitive Data Protection
CCC.ObjStor.CN05Versioning is Enabled for All Objects in the Bucket
Ensure that versioning is enabled for all objects stored in the object storage bucket to enable recovery of previous versions of objects in case of loss or corruption.
CCC.ObjStor.CN05.AR01When an object is uploaded to the object storage bucket, the object MUST be stored with a unique identifier.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.ObjStor.CN05.AR02When an object is modified, the service MUST assign a new unique identifier to the modified object to differentiate it from the previous version.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.ObjStor.CN05.AR03When an object is modified, the service MUST allow for recovery of previous versions of the object.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.ObjStor.CN05.AR04When an object is deleted, the service MUST retain other versions of the object to allow for recovery of previous versions.
Applicability:
tlp-cleartlp-greentlp-ambertlp-red
CCC.Core.THCCC.Core.TH06Data is Lost or Corrupted
CCMDSP-16Data Retention and DeletionDSP-17Sensitive Data Protection
CCC.ObjStor.CN10Restrict Storage Class Transitions to Approved Tiers
Ensure that objects cannot be transitioned to storage classes with lower durability or availability guarantees without explicit authorization, preventing degradation of data resilience through misconfigured lifecycle policies or unauthorized actions.
CCC.ObjStor.CN10.AR01When a lifecycle policy is configured to transition objects to a different storage class, the service MUST prevent transitions to any storage class not included in an organization-defined list of approved tiers.
Applicability:
tlp-greentlp-ambertlp-redRecommendation: Maintain a list of approved storage classes based on durability and availability requirements. Configure service-level policies to reject lifecycle rules targeting unapproved classes.
CCC.ObjStor.CN10.AR02When a manual request is made to change an object's storage class to a tier with lower durability or availability, the service MUST require explicit approval from an identity with elevated privileges.
Applicability:
tlp-ambertlp-redRecommendation: Implement IAM policies that separate storage class modification permissions from general object write permissions. Require secondary authorization for downgrades.
CCC.ObjStor.CN10.AR03When a storage class transition occurs, the service MUST publish an auditable log entry including the identity that initiated the transition, the source and destination classes, and the affected objects.
Applicability:
tlp-greentlp-ambertlp-redRecommendation: Enable logging for all storage class transitions and integrate with monitoring systems to detect unexpected tier changes.
CCC.ObjStor.THCCC.ObjStor.TH03Storage Class Downgrade Leading to Durability or Availability Loss
CCC.Core.THCCC.Core.TH06Data is Lost or Corrupted
CCMDSP-16Data Retention and DeletionDSP-17Sensitive Data ProtectionLOG-08Log Records
CCC.Core.CN06Restrict Deployments to Trust Perimeterimported
Imported from CCC.Core.CN
Ensure that the service and its child resources are only deployed on infrastructure in locations that are explicitly included within a defined trust perimeter.
CCC.Core.CN06.AR01When the service is running, its region and availability zone MUST be included in a list of explicitly trusted or approved locations within the trust perimeter.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redRecommendation: Maintain an up-to-date list of trusted and approved regions based on organizational policies. Validate the service's deployment location is included in this list.
CCC.Core.CN06.AR02When a child resource is deployed, its region and availability zone MUST be included in a list of explicitly trusted or approved locations within the trust perimeter.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redRecommendation: Maintain an up-to-date list of trusted and approved regions based on organizational policies. Validate that child resources can only be deployed to locations included in this list.
CCC.Core.ThreatsCCC.Core.TH03
CCMDSP-19Data Location (specify and document processing and backup locations)
CCC.Core.CN10Restrict Data Replication to Trust Perimeterimported
Imported from CCC.Core.CN
Ensure that data is only replicated on infrastructure in locations that are explicitly included within a defined trust perimeter.
CCC.Core.CN10.AR01When data is replicated, the service MUST ensure that replication only occurs to destinations that are explicitly included within the defined trust perimeter.
Applicability:
tlp-greentlp-ambertlp-red
CCC.Core.ThreatsCCC.Core.TH04
CCMDSP-10Sensitive Data Transfer (only processed within scope as permitted)DSP-19Data Location (specify and document the physical locations of data)
Access
Access control and public exposure boundaries.
CCC.ObjStor.CN07Multi-Factor Authentication Is Required for Object Deletion
Ensure that deletion of objects stored in the object storage system is protected by multi-factor authentication (MFA), reducing the risk of accidental, unauthorized, or compromised-credential–based data destruction.
CCC.ObjStor.CN07.AR01The object storage service MUST support a configuration option that requires MFA to be successfully completed before any object deletion can be attempted, regardless of the request interface.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.ObjStor.CN07.AR02When MFA deletion protection is enabled on a bucket or object namespace, the service MUST deny any deletion request from an identity that has not satisfied the MFA requirement at the time of the request.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.ObjStor.CN07.AR03When an attempt is made to delete an object, the service's audit logs MUST clearly record each deletion attempt, including whether MFA was required and whether validation was met.
Applicability:
tlp-cleartlp-greentlp-ambertlp-red
CCC.Core.THCCC.Core.TH01Prevents unauthorized identities from deleting objectsCCC.Core.TH06Mitigates malicious or accidental data loss through protected deletionCCC.Core.TH17Ensures deletion requests from unauthorized entities do not result in action
CCMDSP-16MFA enforcement strengthens data retention and deletion controlIAM-12MFA required for privileged or destructive operations
CCC.ObjStor.CN02Enforce Uniform Bucket-level Access to Prevent Inconsistent Permissions
Ensure that uniform bucket-level access is enforced across all object storage buckets. This prevents the use of ad-hoc or inconsistent object-level permissions, ensuring centralized, consistent, and secure access management in accordance with the principle of least privilege.
CCC.ObjStor.CN02.AR01When a permission set is allowed for an object in a bucket, the service MUST allow the same permission set to access all objects in the same bucket.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.ObjStor.CN02.AR02When a permission set is denied for an object in a bucket, the service MUST deny the same permission set to access all objects in the same bucket.
Applicability:
tlp-cleartlp-greentlp-ambertlp-red
CCC.Core.THCCC.Core.TH01Access is Granted to Unauthorized Users
CCMIAM-08User Access Review
CCC.ObjStor.CN08Enforce Constraints on Pre-Signed URL Generation
Ensure that pre-signed URLs are generated with minimum necessary permissions, limited expiry durations, and auditable generation events to prevent unauthorized access through leaked or overly permissive URLs.
CCC.ObjStor.CN08.AR01When a pre-signed URL is generated, the service MUST enforce a maximum expiry duration that does not exceed an organization-defined threshold.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redRecommendation: Configure a maximum TTL policy for pre-signed URLs. For sensitive data, consider expiry durations of 15 minutes or less. Review and adjust thresholds based on operational requirements.
CCC.ObjStor.CN08.AR02When a pre-signed URL is generated, the service MUST restrict the URL scope to a single object and a single operation (read or write), preventing broad access grants.
Applicability:
tlp-greentlp-ambertlp-redRecommendation: Ensure application logic generates URLs scoped to individual objects. Avoid wildcard or prefix-based URL generation that could expose multiple objects.
CCC.ObjStor.CN08.AR03When a pre-signed URL is generated, the service MUST publish an auditable log entry that includes the generating identity, the target resource, the granted permissions, and the expiry time.
Applicability:
tlp-greentlp-ambertlp-redRecommendation: Enable logging for all pre-signed URL generation events. Integrate these logs with existing SIEM or monitoring systems for anomaly detection.
CCC.ObjStor.CN08.AR04When a pre-signed URL is generated, the service MUST restrict generation to identities that have explicit permission to create pre-signed URLs, separate from their permission to access the underlying object.
Applicability:
tlp-ambertlp-redRecommendation: Implement a dedicated IAM permission for pre-signed URL generation rather than implicitly granting this capability to all entities with object-level access.
CCC.ObjStor.THCCC.ObjStor.TH02Pre-Signed URL Abuse
CCC.Core.THCCC.Core.TH01Access is Granted to Unauthorized Users
CCMIAM-01IAM Policy and ProceduresDSP-17Sensitive Data ProtectionLOG-08Log Records
CCC.ObjStor.CN09Block Public Access by Default
Ensure that all buckets and objects are protected from public (unauthenticated or anonymous) access by default, requiring explicit and auditable action to override.
CCC.ObjStor.CN09.AR01When a bucket is created, the service MUST enable a public access block that prevents any policy or ACL from granting public access to the bucket or its objects.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redRecommendation: Enable account-level or organization-level public access block settings to ensure all new buckets inherit this protection by default.
CCC.ObjStor.CN09.AR02When an attempt is made to modify a bucket policy or ACL to grant public access, the service MUST deny the modification unless the public access block has been explicitly disabled.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redRecommendation: Configure preventative controls at the organization level so that individual bucket owners cannot bypass the public access block without elevated approval.
CCC.ObjStor.CN09.AR03When an attempt is made to disable the public access block, the service MUST require explicit approval from an identity with elevated privileges and MUST publish an auditable event to a monitored channel.
Applicability:
tlp-greentlp-ambertlp-redRecommendation: Implement an approval workflow or secondary authorization requirement for disabling public access blocks. Ensure all changes are logged and trigger alerts.
CCC.ObjStor.CN09.AR04When the public access block is disabled, the service MUST NOT permit disabling for any bucket containing objects classified at TLP:AMBER or TLP:RED.
Applicability:
tlp-ambertlp-redRecommendation: Use service control policies or organization-level guardrails to permanently enforce public access blocks on buckets containing sensitive data.
CCC.Core.THCCC.Core.TH01Access is Granted to Unauthorized Users
CCMDSP-07Data Protection by Design and DefaultDSP-17Sensitive Data ProtectionIAM-01IAM Policy and Procedures
CCC.Core.CN03Implement Multi-factor Authentication (MFA) for Accessimported
Imported from CCC.Core.CN
Ensure that all sensitive activities require two or more identity factors during authentication to prevent unauthorized access.
CCC.Core.CN03.AR01When an entity attempts to modify the service through a user interface, the authentication process MUST require multiple identifying factors for authentication.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.Core.CN03.AR02When an entity attempts to modify the service through an API endpoint, the authentication process MUST require a credential such as an API key or token AND originate from within the trust perimeter.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.Core.CN03.AR03When an entity attempts to view information on the service through a user interface, the authentication process MUST require multiple identifying factors from the user.
Applicability:
tlp-ambertlp-redCCC.Core.CN03.AR04When an entity attempts to view information on the service through an API endpoint, the authentication process MUST require a credential such as an API key or token AND originate from within the trust perimeter.
Applicability:
tlp-ambertlp-red
CCC.Core.ThreatsCCC.Core.TH01
CCMIAM-14Strong Authentication (Define, implement and evaluate processes - including MFA)
CCC.Core.CN05Prevent Access from Untrusted Entitiesimported
Imported from CCC.Core.CN
Ensure that secure access controls enforce the principle of least privilege to restrict access to authorized entities from explicitly trusted sources only.
CCC.Core.CN05.AR01When an attempt is made to modify data on the service or a child resource, the service MUST block requests from unauthorized entities.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.Core.CN05.AR02When administrative access or configuration change is attempted on the service or a child resource, the service MUST refuse requests from unauthorized entities.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.Core.CN05.AR03When administrative access or configuration change is attempted on the service or a child resource in a multi-tenant environment, the service MUST refuse requests across tenant boundaries unless the origin is explicitly included in a pre-approved allowlist.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.Core.CN05.AR04When data is requested from outside the trust perimeter, the service MUST refuse requests from unauthorized entities.
Applicability:
tlp-ambertlp-redCCC.Core.CN05.AR05When any request is made from outside the trust perimeter, the service MUST NOT provide any response that may indicate the service exists.
Applicability:
tlp-redCCC.Core.CN05.AR06When any request is made to the service or a child resource, the service MUST refuse requests from unauthorized entities.
Applicability:
tlp-greentlp-ambertlp-red
CCC.Core.ThreatsCCC.Core.TH01
CCMDSP-01Security and Privacy Policy and ProceduressDSP-07Data Protection by Design and DefaultDSP-08Data Privacy by Design and DefaultDSP-10Sensitive Data TransferDSP-17Sensitive Data Protection
Observability
The Observability group covers entries related to logging, monitoring, metrics, alerting, and event publication. This includes audit trail integrity, enumeration detection, and protection against tampering or unauthorized access to operational telemetry.
CCC.Core.CN04Log All Access and Changesimported
Imported from CCC.Core.CN
Ensure that all access attempts are logged to maintain a detailed audit trail for security and compliance purposes.
CCC.Core.CN04.AR01When administrative access or configuration change is attempted on the service or a child resource, the service MUST log the client identity, time, and result of the attempt.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.Core.CN04.AR02When any attempt is made to modify data on the service or a child resource, the service MUST log the client identity, time, and result of the attempt.
Applicability:
tlp-ambertlp-redCCC.Core.CN04.AR03When any attempt is made to read data on the service or a child resource, the service MUST log the client identity, time, and result of the attempt.
Applicability:
tlp-red
CCC.Core.ThreatsCCC.Core.TH01
CCMLOG-08Log Records (Generate audit records containing relevant security information)
CCC.Core.CN07Alert on Unusual Enumeration Activityimported
Imported from CCC.Core.CN
Ensure that logs and associated alerts are generated when unusual enumeration activity is detected that may indicate reconnaissance activities.
CCC.Core.CN07.AR01When enumeration activities are detected, the service MUST publish an event to a monitored channel which includes the client identity, time, and nature of the activity.
Applicability:
tlp-ambertlp-redRecommendation: Implement event publication mechanisms and alerts for patterns indicative of enumeration activities, such as repeated access attempts, requests, or liveness probes. Configure alerts to notify security teams of any activities that merit further investigation.
CCC.Core.CN07.AR02When enumeration activities are detected, the service MUST log the client identity, time, and nature of the activity.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redRecommendation: Implement logging mechanisms to capture details of enumeration activities, including client identity, timestamps, and activity nature. Retain logs according to organizational policies, and occasionally review them for patterns that may indicate reconnaissance activities.
CCC.Core.ThreatsCCC.Core.TH15
CCMLOG-05Audit Logs Monitoring and Response (take action on detected anomalies)SEF-05Incident Response Metrics (establish and monitor metrics)
CCC.Core.CN09Ensure Integrity of Access Logsimported
Imported from CCC.Core.CN
Ensure that access logs are always recorded to an external location that cannot be manipulated from the context of the service(s) it contains logs for.
CCC.Core.CN09.AR01When the service is operational, its logs and any child resource logs MUST NOT be accessible from the resource they record access to.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redCCC.Core.CN09.AR02When the service is operational, disabling the logs for the service or its child resources MUST NOT be possible without also disabling the corresponding resource.
Applicability:
tlp-cleartlp-greentlp-ambertlp-redRecommendation: No normal business operations should disable logs, as this could indicate an attempt to cover up unauthorized access. Ensure that logging mechanisms are tightly integrated with service operations, so that logging cannot be disabled without stopping the service itself.
CCC.Core.CN09.AR03When the service is operational, any attempt to redirect logs for the service or its child resources MUST NOT be possible without halting operation of the corresponding resource and publishing corresponding events to monitored channels.
Applicability:
tlp-ambertlp-redRecommendation: No normal business operations should result in the redirection of logs, as this could indicate an attempt to cover up unauthorized access. Ensure that logging configurations are immutable during service operation so that any changes require stopping the service and publishing corresponding events to monitored channels.
CCC.Core.ThreatsCCC.Core.TH07CCC.Core.TH09CCC.Core.TH04
CCMLOG-02Audit Logs Protection (security and retention)LOG-04Audit Logs Access and Accountability (Restrict audit logs access to authorized personnel)LOG-09Log Protection (protects audit records from unauthorized access)