An update from the Cloud Computing Use Cases Google Group on Security in the Cloud.
In a previous post, it was suggested how a well structured framework of security management controls backed by security infrastructure could be used to assure as many security concerns as possible are covered when constructing our use cases:
- Cloud Security Use Cases
- Standards-based Security Services and Patterns
Security Management Controls (based upon standard
APIs and structured data)
Infrastructural Security Areas (based upon low level
schemas / protocol standards)
One must further assume that these services/patterns (from an external, customer point of view) would re-enforce an open cloud marketplace where customers can choose which providers and have consistent security standards they could leverage. Essentially, customers should be able to federate their applications from their enterprise to the cloud and from cloud to cloud while preserving their security model (identities, access control, policies, configurations, metadata, etc.).
To enable federated applications, use cases (regardless of industry) should include federated patterns such as:
- Federated Identity ( using standardized security tokens)
Federated Access Control/Mgmt. (role based, incl.
attributes, entitlements, etc.)
- Federated Single Sign-On (Sign-Off)
Federated Access Control (enforcement, policy, rules,
Federated Configuration Mgmt. (for applications and
to be used during deployment)
- Federated Trust (certificate/key exchange, etc.)
Federated Audit & Compliance
events, logs, reports, etc.)
On the other hand, there would also be a consideration how services / patterns would be used internally (within the cloud data center by the provider and their staff). The implementation/execution of a security (compliance) framework by a cloud provider is also a concern of their customer. So the use cases should include not only a customer view of security, but also an internal view that can be made transparent to the customer to provide a more direct means to instill trust in cloud providers.
We could also list the underlying standards employed for these patterns if
we want that level of granularity (and it exhibits a new security
consideration). Taking the Federated Identity use case we could, for
example, describe it in terms of either 2-party or 3-party
identity providers using SAML 2.0 security tokens.
Will this methodology help us describe the top-level use cases and show who they can apply to various industry/government scenarios?
Are there still other patterns or standards that I may have missed?
One can either respond to this post on the Cloud Computing Use Cases Google Group (http://su.pr/2Be9pA ) in order to consolidate all posts or respond to this post in your group which we monitor.
Looking forward to your comments.