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 protocols,
APIs and structured data)
- Infrastructural Security Areas (based upon low level data
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. user/service
attributes, entitlements, etc.)
- Federated Single Sign-On (Sign-Off)
- Federated Access Control (enforcement, policy, rules, ties to SLA)
- Federated Configuration Mgmt. (for applications and their metadata
to be used during deployment)
- Federated Trust (certificate/key exchange, etc.)
- Federated Audit & Compliance (manage/aggregate/filter security
events, logs, reports, etc.)
- Others???
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.