Bandingkan kewajiban pengoperasian dibandingkan label penerapan
Dihosting sendiri dan SaaS menggambarkan model pengiriman, bukan hasil keamanan atau keandalan yang lengkap. Platform autentikasi yang dihosting sendiri dapat memberi organisasi kontrol lebih besar terhadap infrastruktur sekaligus menambahkan kewajiban pemeliharaan. Layanan SaaS dapat memindahkan sebagian pemeliharaan tersebut ke pemasok sambil menyerahkan konfigurasi pelanggan, akses, dan keputusan data pada organisasi. Perbandingan yang berguna adalah matriks tanggung jawab berbasis bukti untuk layanan sebenarnya, bukan klaim bahwa satu label selalu lebih aman.
Panduan tanggung jawab bersama Microsoft mengilustrasikan bagaimana tanggung jawab berubah di seluruh model lokal, IaaS, PaaS, dan SaaS. Ini juga mengidentifikasi tanggung jawab yang dipegang pelanggan. Sumber ini menjelaskan kerangka cloud Microsoft; ini bukan alokasi kontrak untuk EmailAuth atau bukti bahwa EmailAuth menawarkan produk yang dihosting sendiri. Naskah ini mengusulkan metode perbandingan tanpa menggunakan perangkat lunak atau mengakses infrastruktur.
Tentukan apa yang sebenarnya termasuk dalam setiap opsi
Catat edisi produk yang didukung, model penerapan, batasan lingkungan, penyedia infrastruktur, dan bantuan pemasok yang dijelaskan dalam dokumentasi saat ini atau penawaran yang disetujui. “Dihosting sendiri” dapat berarti perangkat lunak yang dioperasikan pada perangkat keras yang dimiliki atau pada infrastruktur cloud; pengaturan tersebut dapat mengalokasikan tanggung jawab fisik, sistem operasi, dan aplikasi secara berbeda. “Pribadi” mungkin merujuk pada konektivitas jaringan, sumber daya khusus, atau pengaturan kontrak. Tak satu pun dari istilah-istilah ini dapat menggantikan arsitektur konkret dan batasan pendukung.
Tanyakan komponen apa saja yang ada dan siapa yang mengoperasikannya: waktu proses aplikasi, penyimpanan data, antrean, penyerapan laporan, autentikasi, pencadangan, pemantauan, dan antarmuka administratif. Perlakukan daftar ini sebagai pertanyaan, bukan pernyataan bahwa platform menggunakan komponen tersebut. Jika pemasok tidak dapat memberikan bukti untuk opsi penerapan yang diklaim, tandai opsi tersebut sebagai belum diverifikasi daripada mengisi arsitektur dari dokumentasi produk yang berbeda.
Tetapkan pemeliharaan dan ubah kepemilikan
Untuk setiap komponen yang didukung, identifikasi siapa yang melakukan patch, siapa yang menyetujui perubahan, siapa yang menjadwalkan pemeliharaan, dan siapa yang memverifikasi pemulihan. Pemasok dapat mempublikasikan pembaruan sementara pelanggan harus menginstalnya. Layanan terkelola dapat menerapkan pembaruan sementara pelanggan harus menilai perubahan pada integrasi atau kebijakan akses. Tanggung jawab untuk mendistribusikan perbaikan tidak sama dengan tanggung jawab untuk mengonfirmasi bahwa alur kerja pelanggan yang sebenarnya masih berjalan setelahnya.
Kerangka kerja Microsoft membedakan infrastruktur cloud yang mendasarinya dari data pelanggan, identitas, dan konfigurasi. Terapkan perbedaan tersebut pada perbandingan tanpa menyalin matriksnya sebagai kontrak universal. Pemasok sebenarnya harus menyatakan tanggung jawab dan pengecualiannya. Pelanggan harus mengidentifikasi pemilik internal yang disebutkan namanya untuk kewajiban yang masih ada, daripada menugaskannya secara samar-samar ke “TI.” Tanggung jawab yang tidak dimiliki tetap ada meskipun model penerapannya sesuai.
Memetakan ketergantungan eksternal secara eksplisit
Operasi autentikasi mungkin bergantung pada hosting DNS , penyedia pengirim, sistem identitas, sumber laporan, dan pemantauan eksternal. Memindahkan platform tidak secara otomatis memindahkan kendali atas dependensi tersebut. Aplikasi yang dihosting sendiri tidak dapat mengubah perilaku pengiriman pemasok tanpa otoritas terkait, dan dasbor SaaS tidak dapat menjamin bahwa setiap penerima memberikan laporan. Catat pemilik ketergantungan, antarmuka yang didukung, mode kegagalan, dan bukti yang digunakan untuk memverifikasi statusnya.
RFC 9990 mendefinisikan DMARC pelaporan agregat sebagai proses pelaporan yang berbeda. Ketersediaan dan cakupannya tidak dapat disimpulkan hanya dari waktu operasional platform. RFC 9989 mendefinisikan hubungan autentikasi domain, yang juga bergantung pada konfigurasi pengiriman sebenarnya. Matriks operasi harus memisahkan ketersediaan platform dari kelengkapan pengamatan dan kebenaran otentikasi pengirim.
Evaluasi akses dan tanggung jawab penyewa
Panduan identitas multipenyewa Azure membedakan identitas, otorisasi, dan hak. Perbandingan penerapan harus menanyakan siapa yang mengonfigurasi kepercayaan penyedia identitas, peran pengguna, identitas layanan, pengikatan penyewa, dan izin ekspor. Penerapan khusus tidak secara otomatis berarti setiap pengguna di dalamnya harus mengakses semua data. Layanan bersama tidak secara otomatis berarti bahwa data pelanggan terekspos ke seluruh penyewa.
Memerlukan bukti aktual mengenai pengendalian yang didukung dan batasan administratif. Catat akses dukungan pemasok, akses darurat, dan tanggung jawab audit jika berlaku. Jangan berasumsi bahwa kepemilikan pelanggan atas infrastruktur menghilangkan akses pemasok atau bahwa kepemilikan SaaS menghilangkan peran pelanggan dalam mengeluarkan pengguna. Tidak ada izin, akun, atau pengaturan keamanan yang diubah untuk artikel ini; ini adalah pertanyaan untuk tinjauan resmi.
Bandingkan bukti pemulihan dan kapasitas operasional
Tanyakan kewajiban pencadangan, pemulihan, dan pemulihan bencana apa yang ditetapkan oleh masing-masing opsi, komponen apa saja yang dicakup, dan bukti apa yang menunjukkan pemulihan. Konfigurasi cadangan bukanlah tes pemulihan yang berhasil. Pernyataan ketersediaan pemasok bukanlah bukti bahwa data dan integrasi pelanggan individual dapat dipulihkan sesuai kebutuhan pembeli. Catat komitmen aktual yang didukung dan sisa pekerjaan verifikasi pelanggan tanpa menentukan waktu pemulihan.
Perkirakan beban kerja hanya dari masukan organisasi yang disetujui. Mencakup pemeliharaan sistem operasi atau runtime jika dipertahankan, peningkatan aplikasi, respons insiden, tinjauan akses, dukungan integrasi, dan latihan pemulihan. Jangan berasumsi bahwa hosting mandiri lebih murah karena biaya berlangganan berbeda, atau SaaS lebih murah karena pekerjaan infrastruktur kurang terlihat. Draf ini tidak memperhitungkan kebutuhan staf, total biaya atau penghematan. Ini menyediakan kategori untuk perbandingan yang transparan.
Lembar kerja tanggung jawab pengoperasian
Buat satu baris per kewajiban dengan komponen, ketergantungan, pemilik pelanggan, pemilik pemasok, pihak pelaksana, pihak pemberi persetujuan, referensi bukti, pemicu peninjauan, dan kesenjangan yang belum terselesaikan. Bedakan tanggung jawab untuk melaksanakan suatu tugas dari akuntabilitas atas hasilnya. Tambahkan versi penerapan dan referensi kontrak yang didukung sehingga alokasi dapat ditinjau ketika ada perubahan. Jauhkan kredensial dan detail arsitektur sensitif dari salinan yang dibagikan secara luas.
Bagian pengambilan keputusan harus mengidentifikasi kesenjangan yang tidak dapat diterima, pengendalian kompensasi yang disetujui, dan ketergantungan yang memerlukan bukti lebih lanjut. Baris yang ditandai dibagikan harus menyebutkan nama handoff: apa yang dilakukan masing-masing pihak, sinyal apa yang memicu langkah berikutnya, dan siapa yang memverifikasi penyelesaian. “Dibagikan” tanpa handoff yang jelas dapat menyembunyikan batas kegagalan yang paling penting. Lembar kerja yang diusulkan ini belum diisi dengan perjanjian pemasok atau lingkungan operasi yang sebenarnya.
Diagnosis fiktif: pembaruan tanpa pemilik instalasi
Tim fiksi membandingkan layanan terkelola dengan opsi yang dihosting sendiri. Pemasok yang dihosting sendiri berjanji untuk memberikan pembaruan keamanan, dan pembeli pada awalnya memperlakukan patching sebagai milik pemasok. Tinjauan rinci mengungkapkan bahwa pemasok mendistribusikan paket sementara pelanggan harus menjadwalkan instalasi, menilai kompatibilitas dan memverifikasi layanan yang dihasilkan. Tidak ada tim internal yang menerima pekerjaan itu.
Respons yang diusulkan adalah dengan menugaskan pemilik yang berwenang dan menilai kapasitas sebelum memilih opsi, atau memilih pengaturan yang didukung dengan alokasi tanggung jawab yang berbeda. Tim tidak boleh menyatakan produk tidak aman hanya karena adanya kewajiban. Skenario ini fiktif dan tidak menjelaskan penawaran EmailAuth , patch sebenarnya yang terlewat, atau penerapan yang dilakukan selama pekerjaan ini.
Buatlah keputusan dengan kesenjangan yang terlihat
Perbandingan yang dapat dipertahankan menjelaskan kewajiban mana yang berpindah, mana yang tetap, dan ketergantungan mana yang tidak berubah. Ia tidak memperlakukan pengendalian sebagai bukti kompetensi atau outsourcing sebagai bukti cakupan yang lengkap. Model yang dipilih bergantung pada opsi produk yang didukung, kapasitas organisasi, kontrol yang diperlukan, dan komitmen pemasok yang terverifikasi.
Katalog ini memerlukan matriks tanggung jawab operasi dan ketergantungan berbasis bukti. Artefak asli itu tetap terbuka. Tinjauan spesialis manusia, penerapan sumber, jalur produksi, aksesibilitas, dan pelepasan pemilik juga tetap terbuka. Draf ini memberikan kerangka kerja dan latihan fiktif, bukan arsitektur yang diterapkan atau perjanjian tanggung jawab yang disetujui. Publikasi memerlukan bukti terkini mengenai opsi aktual yang dibandingkan dan kepemilikan yang jelas atas karya yang ditahan.