LEARN. PRACTICE. GROW.Responsibilities by service and operation
When migrating a funds application to managed services, replace the statement that the provider handles security with a concrete responsibility matrix. For each service, identify who configures identities, permissions, classification, encryption options, networking, logs, retention and recovery. Abstraction can transfer platform tasks to the provider, but it does not automatically decide who should read the organization’s data. In the AWS managed storage example, the customer remains responsible for asset classification and the permissions applied to those assets. Also assign an owner to check configuration after a change. Infrastructure as code can make review repeatable without guaranteeing that every change passes through the repository or that actual state matches the plan. Compare desired configuration, observed configuration and authorized exceptions. Include operations and emergency accounts in access analysis and record how logs reach the responding team. At a project committee, a task is complete only when responsibility, evidence and acceptance exist for the selected service. This block’s lab is local and provisions no AWS, Azure or GCP resources; cloud decisions are scenarios supported by documentation, requiring separate implementation evidence.
Classification needs an origin and a consequence
Public, internal or confidential classification expresses a decision about data; a label produces protection only when controls use it. Identify the classification owner, the rule for derived datasets and who can change the value. An aggregate can reveal individual positions when groups are very small, even without names. Publication approval should consider that risk rather than relying only on a filename extension. In the lab, a local catalogue maps facts to public and positions to confidential. The client cannot add classification=public to override that authoritative origin. A synthetic sensitive marker inside a public dataset is also blocked on the public route. This combination shows how labeling and inspection can complement each other without demonstrating a complete classifier. For unknown data, define quarantine, review or denial according to purpose; do not automatically assume the least restrictive class. Carry relevant decisions into copies, exports, search indexes and temporary data. During acceptance, verify both the classification decision and the action at the destination, with evidence that can explain exceptions without exposing confidential content in the report. Classification changes require an owner and a reviewable reason.
DLP monitoring and blocking have different outcomes
A DLP policy can detect, warn, allow a justified override or prevent an operation, depending on capabilities and location. Before enabling blocking in a critical service, use synthetic data and authorized samples to evaluate false positives, supported formats and business impact. In the lab’s monitoring mode, a prohibited marker produces a deny decision in the audit record, but transmission is deliberately allowed; the receiver records another arrival. After returning to enforce mode, the same content receives 403 and the receipt count does not increase. An alert dashboard does not establish prevention. Treatment of uninspectable data must also be defined. The example refuses unsupported types and bodies declared as compressed instead of treating them as clean. Identify honest limits too: the spaced pattern SYNTH ACCOUNT 1234 passes a narrow detector that only recognizes the hyphenated form. This negative observation remains a documented limitation rather than being hidden by a success percentage. For production, select controls suitable for each location and exercise encodings, alternative channels, overrides and availability before claiming coverage. A product’s simulation mode must be interpreted according to its documented behavior.
Deleting an object name does not remove every copy
A team decommissions an exporter and presents a GET returning 404 as proof of deletion. In an S3 bucket with versioning enabled, a simple deletion without versionId normally creates a delete marker; earlier versions can remain. The project should inventory versions, replicas, backups, caches, support copies and retention obligations before defining the final state. Distinguish hiding the current version, deleting a particular version and completing treatment of every copy within the request’s scope. Lifecycle configuration also has different rules for current and noncurrent versions. An expiration deadline does not establish that execution has already happened. Define inventory reports, service confirmation and follow-up verification, with justified exceptions when retention prevents immediate deletion. For physical media, sanitization requires an appropriate method and risk-based validation; removing a local lab file does not demonstrate that process. During operational handover, supply a procedure identifying the object and its copies, owner, state, date and completion evidence. Do not use absence from a user interface as a substitute for lifecycle traceability. These cloud observations are documented behavior, not actions executed against a real account.
Keys, data and remanence have related lifecycles
A proposal would delete a KMS key to retire a dataset. Before deciding, identify encrypted data, key copies, cached data keys, replicas and external mechanisms involved. In AWS KMS, scheduling deletion of a customer-managed key starts a waiting period of 7 to 30 days; it does not mean immediate destruction. Pending deletion prevents new cryptographic operations using that key in the service, but applications might retain plaintext data keys obtained earlier. A key in an external key store also depends on external material that deleting the KMS object does not remove. To assess cryptographic erasure as sanitization, determine whether sensitive data was previously stored unencrypted and whether all relevant key copies can be handled. Backups and escrow require their own analysis. In the project, separate the approved request, scheduling, final service confirmation and verification of the covered scope. A poorly planned destructive action can prevent legitimate recovery without satisfying a global deletion objective. This lesson does not execute KMS or certify physical zeroization; it teaches how to frame questions and evidence before approving the procedure, including ownership of copies beyond the application team.
Integrate controls and hand over usable evidence
Prepare an acceptance record for the exporter: data class, allowed destinations, policy origin, transport identity, capacity, observability, limits and operations owner. Connect every decision to a concrete observation. In the two local runs, 33 checks per execution establish actual TLS connections, certificate rejection, policy enforcement, the distinction between observing and blocking, version changes, rollback and failure with the receiver stopped. Each execution creates fresh material and ends with server threads, listeners and temporary keys removed. The report retains message hashes and lengths instead of sensitive content in records. That care does not establish universal anonymization: even metadata can require access and retention controls. The exercise also exposes an unrecognized detector pattern and explicitly excludes cloud tests, distributed propagation, load benchmarks and disk sanitization. Keep those gaps in the project plan with an owner and closure condition. Before production, the team adapts the design to the actual service, validates it with users and operations and exercises relevant failures. Completing a lab informs the decision; it does not replace acceptance in the environment where the service will operate or demonstrate official certification readiness by itself.
# Original local loopback lab; synthetic data only. Requires Python 3 and openssl on PATH.
# Use a NEW directory: existing output directories are refused.
python3 content/labs/securityx-architecture-contracts/run.py --output /tmp/securityx-architecture-fresh-run
# Expected: 33 checks, 5 received synthetic exports; listeners/threads/temporary keys removed.
# No cloud, production DLP, fleet propagation, online revocation or disk sanitization.
Monitor records deny and allows a receipt; enforce blocks the same marker and receiver count does not increase.
Common pitfalls
Confusing alerts with blocking, labels with enforcement, 404 with global deletion and scheduled key deletion with completed sanitization.
Related topics: Architecture and acceptance · Evidence and operational limits
Connect requirements, decision origin, path enforcement and evidence with explicit limits.
Reference: AWS Shared Responsibility Model · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17