Tujuan dari halaman arsitektur adalah untuk mendokumentasikan kontrol arsitektur, tujuan dan keamanan suatu layanan atau proyek. Ini harus mendokumentasikan penyebaran praktik terbaik dari proyek itu.
Ada beberapa bagian kunci pada halaman arsitektur, yang dijelaskan lebih rinci di bawah ini:
Judul, informasi versi, rincian kontak
Uraian dan tujuan proyek
Pengguna utama dan use-cases
Ketergantungan eksternal dan asumsi keamanan yang terkait
Komponen
Diagram arsitektur
Aset data
Analisis dampak aset data
Antarmuka
Bagian ini berisi judul halaman arsitektur, memberikan status tinjauan (draft, siap untuk diperiksa, ditinjau) dan menangkap rilis dan versi proyek (jika relevan). Ini juga mencatat proyek PTL untuk proyek ini, arsitek proyek yang bertanggung jawab untuk memproduksi halaman arsitektur, diagram dan mengerjakan tinjauan (ini mungkin atau mungkin bukan PTL), dan reviewer keamanan.
Bagian ini akan berisi deskripsi singkat tentang proyek untuk memperkenalkan pihak ketiga ke layanan ini. Ini harus satu paragraf atau dua dan bisa cut/paste dari wiki atau dokumentasi lainnya. Sertakan tautan ke presentasi yang relevan dan dokumentasi lebih lanjut jika tersedia.
Sebagai contoh:
"Anchor adalah layanan public key infrastructure (PKI), yang menggunakan validasi permintaan sertifikat otomatis untuk mengotomatisasi keputusan penerbitan. Sertifikat dikeluarkan untuk periode waktu yang singkat (biasanya 12-48 jam) untuk menghindari masalah flawed revocation (pembatalan cacat) yang terkait dengan CRL dan OCSP."
Daftar pengguna primer yang diharapkan dari arsitektur yang diterapkan dan use-case nya. 'Users' bisa jadi aktor atau layanan lainnya di dalam OpenStack.
Sebagai contoh:
End user akan menggunakan sistem untuk menyimpan data sensitif, seperti kunci enkripsi frase, dll.
Cloud administrator akan menggunakan API administratif untuk mengelola kuota sumber daya.
Ketergantungan eksternal adalah item di luar kendali layanan yang diperlukan untuk pengoperasiannya, dan mungkin berdampak pada layanan jika disusupi atau tidak tersedia. Item ini biasanya berada di luar kendali pengembang namun berada dalam kendali pengirim, atau mungkin dioperasikan oleh pihak ketiga. Peralatan harus dianggap sebagai dependensi eksternal.
Sebagai contoh:
Layanan komputasi Nova bergantung pada layanan otentikasi dan otorisasi eksternal. Dalam penyebaran tipikal, ketergantungan ini akan dipenuhi oleh layanan keystone.
Barbican tergantung pada penggunaan alat Hardware Security Module (HSM).
Daftar komponen proyek yang dikerahkan tidak termasuk entitas eksternal. Setiap komponen harus diberi nama dan memiliki deskripsi singkat tentang tujuannya, dan diberi label dengan teknologi utama yang digunakan (misalnya Python, MySQL, RabbitMQ).
Sebagai contoh:
keystone listener process (Python): Proses Python yang mengkonsumsi keystone event yang diterbitkan oleh layanan keystone.
Database (MySQL): Database MySQL untuk menyimpan barbican state data yang terkait dengan entitas yang dikelola dan metadata mereka.
Diagram arsitektur menunjukkan tata letak logis dari sistem sehingga peninjau keamanan dapat melangkah melalui arsitektur dengan tim proyek. Ini adalah diagram logis yang menunjukkan bagaimana komponen berinteraksi, bagaimana mereka terhubung ke entitas eksternal, dan di mana komunikasi melintasi batas kepercayaan. Informasi lebih lanjut tentang diagram arsitektur, termasuk kunci simbol, akan diberikan dalam panduan diagram arsitektur yang akan datang. Diagram dapat ditarik dalam alat yang dapat menghasilkan diagram yang menggunakan simbol pada kunci, namun draw.io <https://draw.io> __ sangat disarankan.
Contoh ini menunjukkan diagram arsitektur barbican:
Aset data adalah data pengguna, data bernilai tinggi, item konfigurasi, token otorisasi atau item lain yang mungkin ditargetkan oleh penyerang. Kumpulan item data akan bervariasi antar proyek, namun secara umum harus dianggap sebagai kelas data yang sangat penting untuk pengoperasian proyek yang dimaksud. Tingkat detail yang dibutuhkan agak tergantung pada konteksnya. Data biasanya dapat dikelompokkan, seperti 'user data', 'secret data', atau 'configuration files', namun mungkin tunggal, seperti 'admin identity token' atau 'user identity token', atau 'database configuration file'.
Aset data harus mencakup pernyataan di mana aset tersebut bertahan.
Sebagai contoh:
Secret data - Passphrases, Encryption Keys, RSA Keys - bertahan di Database [PKCS#11] atau HSM [KMIP] or [KMIP, Dogtag]
RBAC rulesets - bertahan di policy.json
RabbitMQ Credentials - bertahan di barbican.conf
keystone Event Queue Credentials - bertahan di barbican.conf
Middleware configuration - bertahan di paste.ini
Analisis dampak aset data memecah dampak hilangnya kerahasiaan, integritas atau ketersediaan setiap aset data. Arsitek proyek harus berusaha menyelesaikan ini, karena mereka memahami proyek mereka secara terinci, OpenStack Security Project (OSSP) akan menyelesaikannya dengan proyek selama tinjauan keamanan dan cenderung menambahkan atau memperbarui rincian dampaknya.
Sebagai contoh:
RabbitMQ credentials:
Integrity Failure Impact: barbican dan Workers tidak bisa lagi mengakses antrian. Denial of service.
Confidentiality Failure Impact: Seorang penyerang bisa menambahkan tugas baru ke antrian yang akan dilakukan oleh pekerja. Kuota pengguna bisa habis oleh penyerang. DoS. Pengguna tidak akan bisa menciptakan rahasia asli.
Availability Failure Impact: barbican tidak bisa lagi menciptakan rahasia baru tanpa akses ke antrian.
keystone credentials:
Integrity Failure Impact: barbican tidak akan bisa memvalidasi kredensial pengguna dan gagal. DoS.
Confidentially Failure Impact: Pengguna jahat mungkin dapat menyalahgunakan layanan OpenStack lainnya (tergantung pada konfigurasi peran keystone) namun barbican tidak terpengaruh. Jika akun layanan untuk validasi token juga memiliki hak adminican admin, maka pengguna jahat dapat memanipulasi fungsi admin barbican.
Availability Failure Impact: barbican tidak akan bisa memvalidasi kredensial pengguna dan gagal. DoS.
Daftar antarmuka menangkap antarmuka dalam lingkup tinjauan. Ini termasuk koneksi antara blok pada diagram arsitektur yang melintasi batas kepercayaan atau tidak menggunakan protokol enkripsi standar industri seperti TLS atau SSH. Untuk setiap antarmuka informasi berikut diambil:
Protokol yang digunakan
Aset data apa pun yang transit di antarmuka itu
Informasi tentang otentikasi yang digunakan untuk terhubung ke antarmuka itu
Uraian singkat tentang tujuan antarmuka.
Ini dicatat dalam format berikut:
From->To [Transport]:
Assets in flight
Otentikasi?
Deskripsi
Sebagai contoh:
Client->API Process [TLS]:
Assets in flight: Kredensial keystone pengguna, rahasia plaintext, kata kerja HTTP, ID rahasia, jalur
Akses ke kredensial keystone atau rahasia plaintext dianggap sebagai kegagalan keamanan total sistem - antarmuka ini harus memiliki kontrol kerahasiaan dan integritas yang kuat.
Buat daftar sumber daya yang relevan dengan proyek, seperti halaman wiki yang menjelaskan penyebaran dan penggunaannya, dan tautkan ke repositori kode dan presentasi yang relevan.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.