Pernyataan sertifikasi dan kepatuhan¶

Kepatuhan dan keamanan tidak eksklusif, dan harus diatasi bersama. Penerapan OpenStack tidak mungkin memenuhi persyaratan kepatuhan tanpa pengerasan keamanan. Daftar di bawah ini memberi pengetahuan dan panduan dasar bagi para pendiri OpenStack untuk mendapatkan kepatuhan terhadap standar dan sertifikasi pemerintah dan komersial.

Standar komersial¶

Untuk penyebaran komersial OpenStack, kami merekomendasikan SOC 1/2 dikombinasikan dengan ISO 2700 1/2 untuk dianggap sebagai titik awal untuk kegiatan sertifikasi OpenStack. Kegiatan keamanan yang dibutuhkan yang diamanatkan oleh sertifikasi ini memfasilitasi landasan praktik terbaik keamanan dan kriteria kontrol bersama yang dapat membantu dalam mencapai aktivitas kepatuhan yang lebih ketat, termasuk pengesahan dan sertifikasi pemerintah.

Setelah menyelesaikan sertifikasi awal ini, sisa sertifikasi lebih spesifik. Misalnya, pemrosesan transaksi kartu kredit cloud memerlukan PCI-DSS, cloud yang menyimpan informasi perawatan kesehatan memerlukan HIPAA, dan cloud di dalam pemerintah federal mungkin memerlukan sertifikasi FedRAMP / FISMA, dan ITAR.

SOC 1 (SSAE 16) / ISAE 3402¶

Kriteria Service Organization Controls (SOC) didefinisikan oleh American Institute of Certified Public Accountants (AICPA). Kontrol SOC menilai laporan keuangan dan asersi yang relevan dari service provider, seperti kepatuhan terhadap Sarbanes-Oxley Act. SOC 1 adalah pengganti Statement on Auditing Standards No. 70 (SAS 70) Tipe II report. Kontrol ini biasanya mencakup cakupan data fisik.

Ada dua jenis laporan SOC 1:

Tipe 1 - melaporkan kewajaran penyajian deskripsi manajemen tentang sistem organisasi layanan dan kesesuaian rancangan kontrol untuk mencapai tujuan pengendalian terkait yang termasuk dalam deskripsi pada tanggal yang ditentukan.
Tipe 2 - melaporkan kewajaran penyajian deskripsi manajemen tentang sistem organisasi layanan dan kesesuaian desain dan efektivitas operasi kontrol untuk mencapai tujuan pengendalian terkait yang termasuk dalam deskripsi selama periode tertentu.

Untuk lebih jelasnya lihat AICPA Report on Controls at a Service Organization Relevant to User Entities' Internal Control over Financial Reporting.

SOC 2¶

Service Organization Controls (SOC) 2 adalah pengesahan diri terhadap kontrol yang mempengaruhi keamanan, ketersediaan, dan integritas proses sistem yang digunakan oleh organisasi layanan untuk memproses data pengguna dan kerahasiaan dan privasi informasi yang diproses oleh sistem ini. Contoh pengguna adalah mereka yang bertanggung jawab atas tata kelola organisasi layanan, pelanggan dari organisasi layanan, regulator, mitra bisnis, pemasok, dan pihak lain yang memiliki pemahaman tentang organisasi layanan dan kontrolnya.

Ada dua jenis laporan SOC 2:

Tipe 1 - melaporkan kewajaran penyajian deskripsi manajemen tentang sistem organisasi layanan dan kesesuaian rancangan kontrol untuk mencapai tujuan pengendalian terkait yang termasuk dalam deskripsi pada tanggal yang ditentukan.
Tipe 2 - melaporkan keadilan penyajian deskripsi manajemen tentang sistem organisasi layanan dan kesesuaian desain dan efektivitas operasi kontrol untuk mencapai tujuan pengendalian terkait yang termasuk dalam deskripsi sepanjang periode yang ditentukan.

Untuk lebih jelasnya lihat AICPA Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy.

SOC 3¶

Service Organization Controls (SOC) 3 adalah laporan layanan kepercayaan untuk organisasi layanan. Laporan ini dirancang untuk memenuhi kebutuhan pengguna yang menginginkan kepastian kontrol pada organisasi layanan yang berkaitan dengan keamanan, ketersediaan, integritas pemrosesan, kerahasiaan, atau privasi namun tidak memerlukan atau pengetahuan yang diperlukan untuk memanfaatkan secara efektif SOC 2 Report. Laporan ini disiapkan dengan menggunakan AICPA/Canadian Institute of Chartered Accountants (CICA) Trust Services Principles, Criteria, and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy. Karena mereka adalah laporan penggunaan umum, SOC 3 Reports dapat didistribusikan secara gratis atau diposkan di situs web sebagai meterai.

Untuk lebih jelasnya lihat AICPA Trust Services Report for Service Organizations.

ISO 27001/2¶

Standar ISO / IEC 27001/2 menggantikan BS7799-2, dan merupakan spesifikasi untuk Information Security Management System (ISMS). ISMS adalah serangkaian kebijakan dan proses yang komprehensif yang diciptakan dan dikelola oleh sebuah organisasi untuk mengelola risiko terhadap aset informasi. Risiko ini didasarkan pada confidentiality, integrity, and availability (CIA) informasi pengguna. Triad keamanan CIA telah digunakan sebagai landasan bagi sebagian besar bab dalam buku ini.

Untuk lebih jelasnya lihat ISO 27001.

HIPAA / HITECH¶

The Health Insurance Portability and Accountability Act (HIPAA) adalah keputusan kongres Amerika Serikat yang mengatur pengumpulan, penyimpanan, penggunaan dan penghancuran catatan kesehatan pasien. Keputusan tersebut menyatakan bahwa Protected Health Information (PHI) harus diberikan "unusable, unreadable, or indecipherable" kepada orang-orang yang tidak berwenang dan bahwa enkripsi untuk data 'at-rest' dan 'inflight' harus ditangani.

HIPAA bukan sertifikasi, melainkan panduan untuk melindungi data kesehatan. Serupa dengan PCI-DSS, masalah yang paling penting dengan PCI dan HIPPA adalah pelanggaran informasi kartu kredit, dan data kesehatan, tidak terjadi. Dalam kasus pelanggaran, penyedia awan akan diteliti untuk mematuhi kontrol PCI dan HIPPA. Jika terbukti memenuhi syarat, provider dapat diharapkan segera menerapkan remedial controls, melanggar notifikasi pemberitahuan, dan pengeluaran yang signifikan untuk kegiatan kepatuhan tambahan. Jika tidak memenuhi syarat, penyedia awan dapat terancam on-site audit team, denda, potensi kehilangan merchant ID (PCI), dan dampak reputasi besar.

Pengguna atau organisasi yang memiliki PHI harus mendukung persyaratan HIPAA dan entitas tertutup HIPAA. Jika suatu entitas bermaksud untuk menggunakan suatu layanan, atau dalam hal ini, sebuah awan OpenStack yang mungkin menggunakan, menyimpan atau memiliki akses ke PHI tersebut, maka Business Associate Agreement (BAA) harus ditandatangani. BAA adalah kontrak antara entitas tertutup HIPAA dan penyedia layanan OpenStack yang mengharuskan penyedia untuk menangani PHI tersebut sesuai dengan persyaratan HIPAA. Jika penyedia layanan tidak menangani PHI, seperti dengan kontrol keamanan dan pengerasan (hardening), maka mereka tunduk pada denda HIPAA dan denda.

Arsitek OpenStack menafsirkan dan menanggapi pernyataan HIPAA, dengan enkripsi data tetap menjadi praktik inti. Saat ini, ini memerlukan informasi kesehatan terlindungi yang terkandung dalam penerapan OpenStack untuk dienkripsi dengan algoritma enkripsi standar industri. Potensi proyek OpenStack masa depan seperti enkripsi objek akan memfasilitasi pedoman HIPAA untuk mematuhi undang-undang tersebut.

Untuk lebih jelasnya lihat Health Insurance Portability And Accountability Act.

PCI-DSS¶

The Payment Card Industry Data Security Standard (PCI DSS) didefinisikan oleh Payment Card Industry Standards Council, dan dibuat untuk meningkatkan kontrol seputar data pemegang kartu untuk mengurangi kecurangan kartu kredit. Verifikasi kepatuhan tahunan dinilai oleh Qualified Security Assessor (QSA) eksternal yang membuat Report on Compliance (Compliance Comporiance / ROC), atau dengan Self Assessment Questionnaire (SAQ) tergantung pada volume transaksi card-holder.

Pengerahan OpenStack yang menyimpan, memproses, atau mengirimkan rincian kartu pembayaran berada dalam cakupan PCI-DSS. Semua komponen OpenStack yang tidak tersegmentasi dengan benar dari sistem atau jaringan yang menangani data pembayaran termasuk dalam pedoman PCI-DSS. Segmentasi dalam konteks PCI-DSS tidak mendukung multi-tenancy, melainkan pemisahan fisik (host/network).

Untuk lebih jelasnya lihat PCI security standards.

Standar Pemerintah¶

FedRAMP¶

"The Federal Risk and Authorization Management Program (FedRAMP) adalah program pemerintah yang menyediakan pendekatan standar untuk penilaian keamanan, otorisasi, dan pemantauan berkelanjutan untuk produk dan layanan awan. "NIST 800-53 adalah basis untuk FISMA dan FedRAMP yang mengamanatkan kontrol keamanan yang secara khusus dipilih untuk memberikan perlindungan di awan. Lingkungan FedRAMP bisa sangat intensif dari spesifisitas seputar kontrol keamanan, dan volume dokumentasi yang dibutuhkan untuk memenuhi standar pemerintah.

Untuk lebih jelasnya lihat FedRAMP.

ITAR¶

The International Traffic in Arms Regulations (ITAR) adalah seperangkat peraturan pemerintah Amerika Serikat yang mengendalikan ekspor dan impor artikel dan layanan yang berkaitan dengan pertahanan di United States Munitions List (USML) dan data teknis terkait. ITAR sering didekati oleh penyedia awan sebagai "operational alignment" dan bukan sertifikasi formal. Ini biasanya melibatkan penerapan lingkungan awan terpisah mengikuti praktik berdasarkan kerangka NIST 800-53, sesuai persyaratan FISMA, dilengkapi dengan kontrol tambahan yang membatasi akses terhadap "U.S. Persons" saja dan pemutaran latar belakang.

Untuk lebih jelasnya lihat The International Traffic in Arms Regulations (ITAR).

FISMA¶

The Federal Information Security Management Act mensyaratkan bahwa instansi pemerintah membuat rencana komprehensif untuk menerapkan banyak standar keamanan pemerintah, dan diundangkan dalam E-Government Act tahun 2002. FISMA menguraikan sebuah proses, yang memanfaatkan beberapa publikasi NIST, menyiapkan sebuah sistem informasi untuk menyimpan dan memproses data pemerintah.

Proses ini dipecah menjadi tiga kategori utama:

Kategorisasi sistem:: Sistem informasi akan menerima kategori keamanan sebagaimana didefinisikan dalam Federal Information Processing Standards Publication 199 (FIPS 199). Kategori ini mencerminkan potensi dampak kompromi sistem.
Pilihan kontrol:: Berdasarkan kategori keamanan sistem sebagaimana didefinisikan dalam FIPS 199, sebuah organisasi menggunakan FIPS 200 untuk mengidentifikasi persyaratan pengendalian keamanan spesifik untuk sistem informasi. Misalnya, jika sebuah sistem dikategorikan "moderate", sebuah persyaratan dapat dikenalkan untuk mengamanatkan "secure passwords".
Kontrol menyesuaikan:: Setelah kontrol keamanan sistem diidentifikasi, arsitek OpenStack akan menggunakan NIST 800-53 untuk mengekstrak pilihan kontrol yang disesuaikan. Misalnya, spesifikasi apa yang dimaksud dengan "secure password".

Pernyataan sertifikasi dan kepatuhan