Difference between revisions of "2009 - Cloud Computing Bill of Rights - Sam Johnston, James Urquhart, Rich Wellner"
Alan vazser (talk | contribs) m (Alan vazser moved page Sam Johnston, James Urquhart, Rich Wellner (2009) Cloud Computing Bill of Rights to 2009 - Cloud Computing Bill of Rights - Sam Johnston, James Urquhart, Rich Wellner) |
|||
(8 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | + | [[File:Screenshot-web.archive.org 2017-04-25 15-26-05.png|thumbnail|right]] | |
− | |||
− | + | == <small>'''Text'''</small> == | |
+ | '''Cloud Computing Bill of Rights''' | ||
− | [[ | + | '''From Cloud Computing Community Wiki''' |
− | [[ | + | |
− | [[ | + | See also: [https://web.archive.org/web/20090423161829/http://wiki.cloudcommunity.org:80/wiki/Cloud_Computing_Manifesto Cloud Computing Manifesto]. |
− | [[ | + | |
− | [[ | + | <big>'''User rights'''</big> |
+ | |||
+ | '''Auditing''' | ||
+ | |||
+ | 1. '''Events''' must be securely recorded for a period disclosed to and depending on the needs of the user | ||
+ | |||
+ | 2. '''Logs''' must be made available by download in a transparent format and optionally online | ||
+ | |||
+ | 3. '''Monitoring''' should not exceed that required for service delivery, or must be optional | ||
+ | |||
+ | '''Billing''' | ||
+ | |||
+ | 1. '''Itemised Invoices''' must be made available with sufficient information so as to validate the providers' claims | ||
+ | |||
+ | 2. '''Limits''' must be able to be enforced so as to prevent runaway costs | ||
+ | |||
+ | 3. '''Rates''' must be transparent, in that a user should be able to calculate and anticipate usage | ||
+ | |||
+ | 4. '''Usage Data''' (both current and historical) must be available to enable users to monitor usage trends | ||
+ | |||
+ | '''Backups''' | ||
+ | |||
+ | 1. '''Bulk Access''' shall be provided to all user data (including metadata and configuration data) | ||
+ | |||
+ | 2. '''Frequency''' of access shall not be unreasonably limited (eg >30 days[1]) | ||
+ | |||
+ | 3. '''Redundancy''' should be built into the systems such that user data is protected against loss | ||
+ | |||
+ | '''Data''' | ||
+ | |||
+ | 1. '''Encryption''' of data shall be facilitated where feasible and never unnecessarily hindered | ||
+ | |||
+ | 2. '''Integrity''' data integrity expectations will be clearly defined | ||
+ | |||
+ | 3. '''Licensing''' as necessary for delivery of services (eg hosting) is acceptable with explicit permission | ||
+ | |||
+ | 4. '''Metadata''' and configuration data (eg settings) is included | ||
+ | |||
+ | 5. '''Ownership''' is retained by the user along with all associated rights (eg copyright)[2] | ||
+ | |||
+ | 6. '''Subusers' data''' is included (eg Google Apps users have multiple accounts, SalesForce users have customer accounts) | ||
+ | |||
+ | '''Interfaces''' | ||
+ | |||
+ | 1. '''Application Programming Interfacess''' (APIs) shall be maintained for accessing and manipulating data | ||
+ | |||
+ | 2. '''Change control''' shall allow for all API changes to be notified well in advance | ||
+ | |||
+ | 3. '''Documentation''' shall be made available online in open standard formats | ||
+ | |||
+ | 4. '''Superseded versions''' of APIs shall be available for a reasonable period | ||
+ | |||
+ | '''Legal''' | ||
+ | |||
+ | 1. '''Conflicts''' of interest shall be revealed to the user (eg where sponsorship has affected platform choice) | ||
+ | |||
+ | 2. '''Contracts''' shall use clear and easy to understand contract language, striving for the fewest surprises | ||
+ | |||
+ | 3. '''Notice''' of changes (most notably service shutdown) must be given well in advance (ideally months) | ||
+ | |||
+ | 4. '''Termination''' of service agreements without penalty must be possible in the event that Terms of Service changes are not acceptable to the User | ||
+ | |||
+ | 5. '''Warrants''' shall be defended and notified to the user according to a set of published policies, except where forbidden | ||
+ | |||
+ | '''Location''' | ||
+ | |||
+ | 1. '''Location''' of systems and data shall be made available to users, but need not be provided beyond the smallest significant jurisdictional boundary (eg state, country, union of states) | ||
+ | |||
+ | 2. '''Selection''' of an appropriate location based on user preferences shall be provided where feasible (price may vary according to local conditions)[3] | ||
+ | |||
+ | 3. '''Entry points''' (eg URLs) shall be owned by the user to facilitate transition between providers | ||
+ | |||
+ | '''Security''' | ||
+ | |||
+ | 1. '''Access''' to systems must be available in a secure fashion (eg appropriate authentication and transport layer security with appropriate ciphers) | ||
+ | |||
+ | 2. '''Administrative Requests''' be handled using secure processes resistent to social engineering (eg identity verification, proof of control of domain[4]) | ||
+ | |||
+ | 3. '''Change management''' shall be enforced and users shall be notified of changes which affect them in advance (ideally with the option to reject) | ||
+ | |||
+ | 4. '''Confidentiality''' of user data must be strictly maintained | ||
+ | |||
+ | 5. '''Multitenancy''' be strictly enforced such that no user can access or modify the data of any concurrent, former or future user | ||
+ | |||
+ | 6. '''Purging of data''' shall be facilitated as required, including immediate, permanent and secure purging if necessary | ||
+ | |||
+ | '''Service''' | ||
+ | |||
+ | 1. '''Marketing''' shall match service levels and price points (eg never advertise a high service level at a low price point and demand a premium) | ||
+ | |||
+ | 2. '''Availability''' shall be maintained to a suitably high level for the application (typically at least 'three nines': 99.9%) | ||
+ | |||
+ | 3. '''Expectations''' shall be met whether explicit or implied; service delivered shall match expectations and providers (who bear the expense in full) will spare no expense in meeting them | ||
+ | |||
+ | 4. '''Service Level Agreements''' shall be clear, concise and backed by financial penalties where they are offered, and alternatives should be offered | ||
+ | |||
+ | 5. '''Support''' shall be provided in a timely fashion, typically 24x7 with 1hr response for severity 0 (however subusers may or may not be assisted by provider) | ||
+ | |||
+ | '''Standards''' | ||
+ | |||
+ | 1. '''Existing standards''' shall be used where possible in preference to creating new standards | ||
+ | |||
+ | 2. '''Open Standards''' should be used where appropriate standards are available (eg REST) | ||
+ | |||
+ | 3. '''Proprietary Standards''' shall not be used or supported in a fashion that could impair innovation | ||
+ | |||
+ | 4. '''Transparent''' data formats shall be used, except where the user explicitly stores opaque data (eg by uploading a proprietary document) | ||
+ | |||
+ | '''Acknowledgements''' | ||
+ | |||
+ | * Sam Johnston prepared this document based on existing efforts and contributed to it | ||
+ | * James Urquhart refined a draft document over a number of blog posts[5][6] | ||
+ | * Rich Wellner contributed a pre-prepared draft document for incorporation | ||
+ | |||
+ | '''References''' | ||
+ | |||
+ | [1] [http://web.archive.org/web/20090217100940/http://blog.dreamhosters.com:80/2008/07/04/dreamhost-newsletter-july-2008/ DreamHost Newsletter – July 2008] | ||
+ | |||
+ | [2] [http://web.archive.org/web/20090419152642/http://www.wesabe.com:80/page/security wesabe: Data Bill of Rights] | ||
+ | |||
+ | [3] [http://web.archive.org/web/20090513072820/http://www.ddj.com:80/architect/202803151 Amazon S3 Storage Now Available In Europe] | ||
+ | |||
+ | [4] [http://web.archive.org/web/20090122060407/http://www.google.com:80/support/a/bin/answer.py?answer=45848&ctx=enteduar#D Google Apps Domain Verification] | ||
+ | |||
+ | [5] [http://web.archive.org/web/20090523175200/http://blog.jamesurquhart.com:80/2008/08/cloud-computing-bill-of-rights.html The Cloud Computing Bill of Rights] | ||
+ | |||
+ | [6] [http://web.archive.org/web/20090523175200/http://blog.jamesurquhart.com:80/2008/08/cloud-computing-bill-of-rights.html Update: The Cloud Computing Bill of Rights] | ||
+ | |||
+ | == <small>'''File'''</small> == | ||
+ | |||
+ | [[File:Cloud Computing Bill of Rights - Cloud Computing Community Wiki.pdf|thumbnail]] | ||
+ | |||
+ | == <small>'''Links'''</small> == | ||
+ | |||
+ | '''Wayback Machine:''' https://web.archive.org/web/20090430192826/http://wiki.cloudcommunity.org/wiki/Cloud_Computing_Bill_of_Rights | ||
+ | |||
+ | '''Wikipedia:''' https://en.wikipedia.org/wiki/Cloud_Computing_Manifesto | ||
+ | |||
+ | '''See also:''' | ||
+ | |||
+ | * [[Reuven_Cohen_(et_al.)_(2009)_The_Open_Cloud_Manifesto_Draft_1.0.9|Reuven Cohen (et al.) (2009) The Open Cloud Manifesto Draft 1.0.9.]] | ||
+ | * [[Reuven_Cohen_(et_al.)_(2009)_Open_Cloud_Manifesto#Links|Reuven Cohen (et al.) (2009) Open Cloud Manifesto.]] | ||
+ | * [[Reuven_Cohen,_Steve_Martin,_Sam_Johnston_(2009)_Cloud_Computing_Manifesto|Reuven Cohen, Steve Martin, Sam Johnston (2009) Cloud Computing Manifesto.]] | ||
+ | |||
+ | [[Category:Manifestos]] | ||
+ | [[Category:Sam Johnston]] | ||
+ | [[Category:James Urquhart]] | ||
+ | [[Category:Rich Wellner]] | ||
+ | [[Category:Cloud Computing Community Wiki]] | ||
+ | [[Category:English]] | ||
+ | [[Category:USA]] | ||
+ | [[Category:2009]] |
Latest revision as of 21:54, 16 February 2018
Text
Cloud Computing Bill of Rights
From Cloud Computing Community Wiki
See also: Cloud Computing Manifesto.
User rights
Auditing
1. Events must be securely recorded for a period disclosed to and depending on the needs of the user
2. Logs must be made available by download in a transparent format and optionally online
3. Monitoring should not exceed that required for service delivery, or must be optional
Billing
1. Itemised Invoices must be made available with sufficient information so as to validate the providers' claims
2. Limits must be able to be enforced so as to prevent runaway costs
3. Rates must be transparent, in that a user should be able to calculate and anticipate usage
4. Usage Data (both current and historical) must be available to enable users to monitor usage trends
Backups
1. Bulk Access shall be provided to all user data (including metadata and configuration data)
2. Frequency of access shall not be unreasonably limited (eg >30 days[1])
3. Redundancy should be built into the systems such that user data is protected against loss
Data
1. Encryption of data shall be facilitated where feasible and never unnecessarily hindered
2. Integrity data integrity expectations will be clearly defined
3. Licensing as necessary for delivery of services (eg hosting) is acceptable with explicit permission
4. Metadata and configuration data (eg settings) is included
5. Ownership is retained by the user along with all associated rights (eg copyright)[2]
6. Subusers' data is included (eg Google Apps users have multiple accounts, SalesForce users have customer accounts)
Interfaces
1. Application Programming Interfacess (APIs) shall be maintained for accessing and manipulating data
2. Change control shall allow for all API changes to be notified well in advance
3. Documentation shall be made available online in open standard formats
4. Superseded versions of APIs shall be available for a reasonable period
Legal
1. Conflicts of interest shall be revealed to the user (eg where sponsorship has affected platform choice)
2. Contracts shall use clear and easy to understand contract language, striving for the fewest surprises
3. Notice of changes (most notably service shutdown) must be given well in advance (ideally months)
4. Termination of service agreements without penalty must be possible in the event that Terms of Service changes are not acceptable to the User
5. Warrants shall be defended and notified to the user according to a set of published policies, except where forbidden
Location
1. Location of systems and data shall be made available to users, but need not be provided beyond the smallest significant jurisdictional boundary (eg state, country, union of states)
2. Selection of an appropriate location based on user preferences shall be provided where feasible (price may vary according to local conditions)[3]
3. Entry points (eg URLs) shall be owned by the user to facilitate transition between providers
Security
1. Access to systems must be available in a secure fashion (eg appropriate authentication and transport layer security with appropriate ciphers)
2. Administrative Requests be handled using secure processes resistent to social engineering (eg identity verification, proof of control of domain[4])
3. Change management shall be enforced and users shall be notified of changes which affect them in advance (ideally with the option to reject)
4. Confidentiality of user data must be strictly maintained
5. Multitenancy be strictly enforced such that no user can access or modify the data of any concurrent, former or future user
6. Purging of data shall be facilitated as required, including immediate, permanent and secure purging if necessary
Service
1. Marketing shall match service levels and price points (eg never advertise a high service level at a low price point and demand a premium)
2. Availability shall be maintained to a suitably high level for the application (typically at least 'three nines': 99.9%)
3. Expectations shall be met whether explicit or implied; service delivered shall match expectations and providers (who bear the expense in full) will spare no expense in meeting them
4. Service Level Agreements shall be clear, concise and backed by financial penalties where they are offered, and alternatives should be offered
5. Support shall be provided in a timely fashion, typically 24x7 with 1hr response for severity 0 (however subusers may or may not be assisted by provider)
Standards
1. Existing standards shall be used where possible in preference to creating new standards
2. Open Standards should be used where appropriate standards are available (eg REST)
3. Proprietary Standards shall not be used or supported in a fashion that could impair innovation
4. Transparent data formats shall be used, except where the user explicitly stores opaque data (eg by uploading a proprietary document)
Acknowledgements
- Sam Johnston prepared this document based on existing efforts and contributed to it
- James Urquhart refined a draft document over a number of blog posts[5][6]
- Rich Wellner contributed a pre-prepared draft document for incorporation
References
[1] DreamHost Newsletter – July 2008
[2] wesabe: Data Bill of Rights
[3] Amazon S3 Storage Now Available In Europe
[4] Google Apps Domain Verification
[5] The Cloud Computing Bill of Rights
[6] Update: The Cloud Computing Bill of Rights
File
File:Cloud Computing Bill of Rights - Cloud Computing Community Wiki.pdf
Links
Wayback Machine: https://web.archive.org/web/20090430192826/http://wiki.cloudcommunity.org/wiki/Cloud_Computing_Bill_of_Rights
Wikipedia: https://en.wikipedia.org/wiki/Cloud_Computing_Manifesto
See also: