Object Storage

Layanan OpenStack Object Storage (swift) menyediakan perangkat lunak yang menyimpan dan mengambil data melalui HTTP. Objek (blobs of data) disimpan dalam hirarki organisasi yang menawarkan akses anonymous read-only, akses yang ditentukan ACL, atau bahkan akses sementara. Object Storage mendukung beberapa mekanisme otentikasi berbasis token yang diimplementasikan melalui middleware.

Aplikasi menyimpan dan mengambil data dalam Object Storage melaluiindustry-standard HTTP RESTful API. Komponen back end Object Storage mengikuti model RESTful yang sama, meskipun beberapa API, seperti yang mengelola daya tahan, dirahasiakan ke cluster. Untuk detail lebih lanjut tentang API lihat OpenStack Storage API.

Komponen Object Storage dikelompokkan ke dalam kelompok primer berikut:

1. Layanan Proxy

2. Layanan Auth

3. Layanan Storage

   • Layanan Account

   • Layanan Container

   • Layanan Object

Diagram contoh dari OpenStack Object Storage Administration Guide (2013)

Catatan

Instalasi Object Storage tidak harus ada di Internet dan juga bisa menjadi awan private dengan tombol publik sebagai bagian dari infrastruktur jaringan internal organisasi.

Keamanan jaringan

Mengamankan layanan bject Storage dimulai dengan mengamankan komponen jaringan. Jika Anda melewatkan bab jaringan, kembali ke Networking.

Protokol rsync digunakan antara node layanan penyimpanan untuk mereplikasi data untuk ketersediaan tinggi. Selain itu, layanan proxy berkomunikasi dengan layanan penyimpanan saat menyampaikan data bolak-balik antara titik end-point dan lingkungan awan.

Hati-hati

Object Storage tidak menggunakan enkripsi atau otentikasi dengan komunikasi antar node. Inilah sebabnya mengapa Anda melihat private switch atau private network ([V] LAN) dalam diagram arsitektur. Data domain ini harus terpisah dari jaringan data OpenStack lainnya. Untuk pembahasan lebih lanjut tentang domain keamanan silahkan lihat Batas dan ancaman keamanan.

Tip

Gunakan segmen jaringan (V)LAN pribadi untuk node penyimpanan Anda di domain data.

Ini mengharuskan bahwa node proxy memiliki dua antarmuka (fisik atau virtual):

1. Salah satunya sebagai antarmuka publik bagi konsumen untuk mencapainya.

2. Lain sebagai antarmuka pribadi dengan akses ke node penyimpanan.

Gambar berikut menunjukkan satu kemungkinan arsitektur jaringan.

Object Storage network architecture with a management node (OSAM)

Keamanan layanan umum

Jalankan layanan sebagai pengguna non-root

Sebaiknya konfigurasikan layanan Object Storage untuk berjalan di bawah akun layanan non-root (UID 0). Satu rekomendasi adalah nama pengguna swift dengan grup utama swift. Layanan Object Storage meliputi, misalnya, proxy-server, container-server, account-server. Langkah-langkah rinci untuk setup dan konfigurasi dapat ditemukan di Add Object Storage chapter dari Installation Guide di OpenStack Documentation index.

Catatan

Tautan di atas default ke versi Ubuntu.

Izin file

Direktori /etc/swift berisi informasi tentang topologi ring dan konfigurasi lingkungan. Izin berikut direkomendasikan:

# chown -R root:swift /etc/swift/*
# find /etc/swift/ -type f -exec chmod 640 {} \;
# find /etc/swift/ -type d -exec chmod 750 {} \;

Ini membatasi hanya root untuk dapat memodifikasi file konfigurasi sambil membiarkan layanan membacanya melalui keanggotaan grup mereka di grup swift .

Mengamankan layanan penyimpanan

Berikut adalah listening port default untuk berbagai layanan penyimpanan:

Service name	Port	Tipe
Layanan Account	6002	TCP
Layanan Container	6001	TCP
Object Service	6000	TCP
Rsync [1]	873	TCP

[1]

Jika ssync digunakan sebagai pengganti rsync, port layanan objek digunakan untuk menjaga daya tahan.

Penting

Otentikasi tidak terjadi pada node penyimpanan. Jika Anda dapat terhubung ke node penyimpanan di salah satu port ini, Anda dapat mengakses atau memodifikasi data tanpa otentikasi. Untuk mengatasi masalah ini, Anda harus mengikuti rekomendasi yang diberikan sebelumnya tentang penggunaan jaringan penyimpanan pribadi.

Terminologi akun Object Storage

Akun Object Storage bukanlah akun pengguna atau kredensial. Berikut ini menjelaskan hubungan:

Akun OpenStack Object Storage	Koleksi kontainer; bukan akun pengguna atau autentikasi. Pengguna mana yang terkait dengan akun dan bagaimana mereka dapat mengaksesnya bergantung pada sistem autentikasi yang digunakan. Lihat :ref: Object_Storage_authentication.
Kontainer OpenStack Object Storage	Koleksi obyek. Metadata pada kontainer tersedia untuk ACL. Arti ACL tergantung pada sistem otentikasi yang digunakan.
Obyek OpenStack Object Storage	Objek data sebenarnya. ACL pada tingkat objek juga dimungkinkan dengan metadata dan bergantung pada sistem otentikasi yang digunakan.

Pada setiap tingkat, Anda memiliki ACL yang mendikte siapa yang memiliki jenis akses apa. ACL ditafsirkan berdasarkan sistem autentikasi yang digunakan. Dua jenis penyedia otentikasi yang paling umum digunakan adalah layanan Identity (keystone) dan TempAuth. Penyedia otentikasi kustom juga dimungkinkan. Lihat :ref: object_storage_authentication untuk informasi lebih lanjut.

Mengamankan layanan proxy

Sebuah node proxy harus memiliki setidaknya dua antarmuka (fisik atau virtual): satu publik dan satu pribadi. Firewall atau layanan yang mengikat bisa melindungi antarmuka publik. Layanan yang dihadapi publik adalah server web HTTP yang memproses permintaan klien end-point, mengotentikasi mereka, dan melakukan tindakan yang sesuai. Antarmuka pribadi tidak memerlukan layanan listening, namun digunakan untuk membuat koneksi keluar ke node penyimpanan pada jaringan penyimpanan pribadi.

HTTP listening port

Anda harus mengkonfigurasi layanan web Anda sebagai pengguna non-root (no UID 0) seperti swift yang disebutkan sebelumnya. Penggunaan port yang lebih besar dari 1024 diperlukan untuk mempermudah dan menghindari menjalankan bagian penampung web sebagai root. Biasanya, klien yang menggunakan HTTP REST API dan melakukan autentikasi secara otomatis mengambil full REST API URL yang mereka butuhkan dari respons autentikasi. REST API OpenStack memungkinkan klien mengautentikasi ke satu URL dan kemudian diberi tahu untuk menggunakan URL yang sama sekali berbeda untuk layanan sebenarnya. Misalnya, Klien mengotentikasi https://identity.cloud.example.org:55443/v1/auth dan mendapat tanggapan dengan kunci autentikasi dan Storage URL (URL dari nodus proxy atau penyeimbang beban) https: / /swift.click.example.org:44443/v1/AUTH_8980.

Metode untuk mengonfigurasi server web Anda agar dijalankan dan dijalankan sebagai pengguna non-root berbeda-beda menurut server web dan sistem operasi.

Load balancer (penyeimbang beban)

Jika pilihan untuk menggunakan Apache tidak layak, atau untuk kinerja yang Anda inginkan untuk melepaskan pekerjaan TLS Anda, Anda dapat menggunakan perangkat penyeimbang beban jaringan khusus. Ini adalah cara yang umum untuk memberikan redundansi dan load balancing saat menggunakan beberapa node proxy.

Jika Anda memilih untuk melepaskan TLS Anda, pastikan bahwa hubungan jaringan antara penyeimbang beban dan nodus proxy Anda berada pada segmen private (V)LAN sehingga node lain di jaringan (kemungkinan dikompromikan) tidak dapat menyadap (mengendus) lalu lintas yang tidak dienkripsi. Jika pelanggaran semacam itu terjadi, penyerang bisa mendapatkan akses ke kredensial klien endpoint atau kredensial administrator awan dan mengakses data awan.

Layanan otentikasi yang Anda gunakan, seperti layanan Identity (keystone) atau TempAuth, akan menentukan bagaimana Anda mengkonfigurasi URL yang berbeda dalam tanggapan ke klien end-point sehingga mereka menggunakan penyeimbang beban Anda daripada sebuah node proxy individual.

Otentikasi Object Storage

Object Storage menggunakan model WSGI untuk menyediakan kemampuan middleware yang tidak hanya menyediakan perluasan secara umum, namun juga digunakan untuk otentikasi klien end-point. Penyedia otentikasi menentukan peran dan jenis pengguna yang ada. Beberapa menggunakan nama pengguna dan kredensial kata kunci tradisional, sementara yang lain mungkin memanfaatkan token kunci API atau sertifikat x.509 sisi klien. Penyedia kustom dapat diintegrasikan dalam menggunakan middleware kustom.

Object Storage dilengkapi dengan dua modul middleware otentikasi secara default, salah satunya dapat digunakan sebagai kode contoh untuk mengembangkan middleware otentikasi kustom.

TempAuth

TempAuth adalah otentikasi default untuk Object Storage. Berbeda dengan Identity, ia menyimpan akun pengguna, kredensial, dan metadata dalam penyimpanan objek itu sendiri. Informasi lebih lanjut dapat ditemukan di bagian ini The Auth System dari dokumentasi Object Storage (swift).

Keystone

Keystone adalah penyedia Identitas yang umum digunakan di OpenStack. Ini juga bisa digunakan untuk otentikasi di Object Storage. Cakupan pengamanan keystone i sudah tersedia di Identitas.

Barang penting lainnya

Di /etc/swift, pada setiap simpul, ada pengaturan swift_hash_path_prefix dan pengaturan swift_hash_path_suffix. Ini disediakan untuk mengurangi kemungkinan benturan hash untuk objek yang disimpan dan mencegah satu pengguna menimpa data pengguna lain.

Nilai ini pada awalnya harus ditetapkan dengan generator bilangan acak yang aman secara kriptografi dan konsisten di semua simpul. Pastikan itu dilindungi dengan ACL yang benar dan Anda memiliki salinan cadangan untuk menghindari kehilangan data.