3.2 Close An Account
Actors: unidentified-user, cloud-subscriber, cloud-provider, payment-broker.
Goals: Close an existing account for a cloud-subscriber.
Assumptions: A cloud-subscriber accesses a cloud-provider's account management web page to receive information about closing an account. Account closure requires the date and time that the account should be closed as well as the method for disposition of data (returning data to cloud-subscriber and deletion of data from cloud-provider's system). We assume one account per cloud-subscriber.
Success Scenario (close, IaaS, PaaS, SaaS): The cloud-subscriber interacts with the cloud-provider's account management web page and requests that their account be closed on a particular date and time. The cloud-subscriber optionally requests the return of data stored with the cloud-provider to the cloud-subscriber (See Use Case "Copy Data Objects Out of a Cloud") or a transfer of data to a different cloud-provider (See Use Case "Copy Data Objects between Cloud Providers). In addition, the cloud-subscriber optionally specifies the data erase procedure to be performed by the cloud-provider after any copy operations have been performed (See Use case "Erase Data Objects in a Cloud"). The cloud-provider: (1) performs the requested actions on the timetable requested; (2) charges the cloud-subscriber according to the terms of the service; (3) notifies the cloud-subscriber that the account has been closed within an agreed to amount of time after the account closes; (4) deletes the cloud-subscriber's payment-broker information from the cloud-provider's systems; and (5) revokes the cloud-subscriber's authentication information. Now the cloud-subscriber is classified as an unidentified-user.
Failure Conditions: (1) the cloud-provider closes the account too early or after the requested time and date; (2) an unauthorized user accesses a cloud-provider's account management web page and impersonates the real cloud-subscriber and closes the account; (3) the requested disposition of data is not faithfully executed; (4) the cloud-provider does not completely delete the cloud-subscriber's payment-broker information; (5) the cloud-provider overcharges the cloud-subscriber; (6) cloud-provider fails to notify the cloud-subscriber the account is closed; (7) cloud-provider fails to revoke the cloud-subscriber's authentication information.
Failure Handling: For (1) the cloud-subscriber will need to contact the cloud-provider to reinstate the account if it was closed too early and, if too late, the cloud-provider may inadvertently give away free service; For (2) the cloud-subscriber will need to contact the cloud-provider and the cloud-provider will need to reinstate the account; For (3) only the cloud-provider will know unless a data leak is discovered by the cloud-subscriber. If that happens, cloud-subscriber must confront the cloud-provider. (See Use Case "Erase Data Objects In a Cloud"); For (4), only the cloud-provider will know unless the cloud-subscriber continues to be billed. If that happens, cloud-subscriber must confront cloud-provider. (See Use Case "Erase Data Objects In a Cloud"); For (5), cloud-subscriber must confront cloud-provider; For (6) cloud-subscriber should contact cloud-provider if time window for notification is exceeded; For (7) cloud-provider retries its revocation procedure.
Note: We might want to consider non-repudiation for some important cloud-provider messages; e.g., when an account gets closed, perhaps the cloud-provider should send a time-stamped and signed message to the former cloud-subscriber that asserts the means that were used to ensure that the cloud-subscriber's data were completely removed (e.g., merely-unlinked, zero-writing memory/disk, n-pass overwrite). An efficient market would price these various erasure methods very differently. While such messages would not enforce erasure methods and could easily be faked, they would be hard evidence about the cloud-provider's intended behavior and could serve as a basis for third party audits.