Dikirim oleh: Andrey Pinchuk | Pengembang Senior AEM Bersertifikat
Bayangkan situasinya: Anda tidur nyenyak dan melihat mimpi ketiga Anda, ketika tiba-tiba telepon berdering - klien yang tidak puas mengeluh bahwa keseluruhan sistem tidak tersedia. Setuju, acara semacam itu tidak nyaman bagi kehidupan pengembang AEM, seluruh tim, dan penyedia solusi. Tidak ada yang bisa dilakukan, kebangkitan awal dan pencarian solusi di depan.
Untuk mencegah momen tanpa sukacita seperti itu terjadi dalam kehidupan profesional Anda, saya akan memberi tahu Anda tentang masalah keamanan tipikal dan cara mengasuransikannya dengan lebih baik.
Saya akan mematuhi rencana seperti itu:
- Keamanan di tingkat Penulis;
- Publikasikan tingkat keamanan;
- Keamanan Dispatcher
- Perlindungan kerangka CSRF;
- Serangan DDoS.
Tip Keamanan Dasar Adobe Experience Manager
Dunia proyek AEM akan menjadi lebih baik jika setiap pengembang memiliki pemahaman yang sama tentang bagaimana seluruh platform dapat dilindungi dari kebocoran data. Menurut diagram di bawah ini, kami memiliki penulis, beberapa penerbit dan dua atau lebih operator (yang disebut penyeimbang). Faktanya, ketiga level ini layak diperhatikan sejak awal dalam hal perlindungan data. Ini adalah aturan kerja klasik yang umumnya diterima di komunitas AEM di seluruh dunia.
1. Gunakan HTTPS . AEM berkembang pesat, memberikan fleksibilitas untuk membuat penulis di protokol lain yang lebih aman. Cukup untuk menghasilkan kunci "SSL Wizard", buat jalur untuk itu dan, dengan demikian, gunakan protokol yang lebih aman. Dalam rekomendasi dari Adobe - langkah ini justru merupakan prioritas pertama dalam keamanan.
2. Instal paket dengan pembaruan terbaru. Proses standar pengembang mengacu pada kenyataan bahwa ketika mengerjakan komponen dan layanan, Anda harus mencari solusi di Google. Tujuan dari langkah ini adalah untuk secara teratur memonitor Service pack & Hot Fixes. Kemudian banyak masalah hilang, termasuk yang terkait dengan keamanan data. Meskipun ini bukan obat mujarab, poin pentingnya adalah menjaga sistem tetap mutakhir.
3. Membuat halaman yang rapi dengan pesan kesalahan. Jika Anda awalnya membuat halaman dengan deskripsi singkat tentang kesalahan, klien akan segera melihat bahwa itu tidak berfungsi, sementara pengembang sudah dalam proses menyelesaikan masalah. Adalah logis bahwa informasi ini tidak akan melewati Anda, tetapi Anda akan menghindari kepanikan dari klien dan penguji, kebingungan dalam tugas.
4. Menolak untuk mengatur kata sandi dan login di "admin-admin". Itu tidak akan lucu, tetapi masalah dengan kualitas login dan kata sandi yang buruk cukup umum bahkan di AEM. Akibatnya, dalam mengejar kecepatan atau pertimbangan lain, kami mendapatkan sistem yang paling rentan. Setelah Anda menemukan bahwa detail masuk primitif telah diatur, cobalah untuk meyakinkan tim / atasan dan mengubahnya menjadi yang lebih andal secepat mungkin.
Keamanan di Tingkat Penulis
Pertama, gunakan vpn . Menggunakan Virtual Protected Network adalah pekerjaan dari jaringan pribadi yang aman untuk membuat koneksi yang aman antara Anda dan server. Ini adalah alat yang sederhana dan penting: karena lalu lintas Anda akan dienkripsi, tidak mungkin untuk mengetahui dari mana Anda mengirim data Anda. Ternyata dengan vPn tidak ada yang akan dapat mengakses instance Anda.
Pendekatan ini cocok untuk pengembang jarak jauh dan semua yang pekerjaannya dilakukan dari lokasi yang berbeda dengan koneksi internet yang tidak stabil.
Kedua, "penulis" Anda harus selalu ditutup, termasuk dari Google . Jadi Anda dapat mengambil kata sandi dan meretas sistem: karena kelalaian, penulis dapat diindeks. Untuk memeriksa kerentanan Anda di mesin pencari, ketik baris domain Anda dan penulis dan jalur ke crx. Ya, Anda dapat menghubungi Yandex atau Google dengan permintaan untuk menghapus garis seperti itu di SERP. Tetapi, sementara masalah ini sedang diselesaikan, sistem sudah akan tersedia untuk umum.
Ketiga, jangan meremehkan hak istimewa pengguna "admin" , yang paling sering memiliki kemampuan untuk melakukan operasi apa pun yang tersedia.
Ini sangat penting pada saat seorang karyawan mengucapkan selamat tinggal kepada perusahaan. Memang, bagi sebagian besar bisnis, akses ke instance bukan pribadi, tetapi melalui satu akun administrator. Lebih logis untuk melakukan yang sebaliknya dan menyadari perubahan spesifik dalam sistem dari penulis tertentu.
AEM 6.1 memperkenalkan pendekatan baru di mana Anda dapat menetapkan hak spesifik untuk bundel atau layanan pengguna. Tetapi lebih baik membuat profil pribadi: menyenangkan bagi karyawan, dan lebih mudah bagi bisnis untuk melacak siapa yang memiliki tingkat akses ke sistem apa. Pendekatan ini relevan untuk tingkat penulis dan penerbit.
Publikasikan Keamanan
Sebagai aturan, hanya setelah lama di proyek mereka menyadari bahwa mereka tidak memeriksa pengguna anonim. Dan sementara pengguna biasa mungkin memiliki pembatasan operasi, pengguna anonim - sering terjadi, memiliki lebih banyak hak untuk melakukan operasi.
Filter Apache Sling Referrer adalah mekanisme yang nyaman dan efektif untuk membuat aplikasi Anda aman. Misalnya, kirim metrik ke AEM, Anda melihat informasi tentang pengiriman data di Kotak Masuk. Jika Anda melebihi nilai default, sistem pihak ketiga dapat mengirim permintaan ini. Ini berarti bahwa siapa pun tidak akan dapat mengirim permintaan. Anda memasukkan domain ke dalam konfigurasi, pada saat permintaan, itu membandingkannya dengan data yang dimasukkan sebelumnya dan, jika semuanya cocok, integrasi terjadi.
Ini akan berubah untuk melakukan konfigurasi yang lebih fleksibel dengan filter: Anda dapat menentukan permintaan, metode, host. Juga ada nilai kosong atau tanda bintang untuk pertanyaan yang lebih rinci.
Keamanan di Tingkat Dispatcher
Pengembang menghadapi perselisihan dalam 10% kasus. Jadi, ini adalah file konfigurasi utama, tempat kami menetapkan jenis URL (larangan / izinkan).
Biasanya, pengembang melakukan tugas kecil, membuat aturan dan lupa bahwa itu akan menambah kerentanan. Agar tidak ada yang mencoba menyerang instance Anda, Anda perlu memeriksa url dengan pemilih pada saat ketersediaan.
Melalui file konfigurasi, Anda dapat menentukan pemrosesan header. Karena semakin akurat Anda menentukan zag, metode, dll., Pengaturan terperinci seperti itu pasti tidak akan merusak apa pun. Ini adalah contoh dasar. Bagaimana jika ada ratusan aturan seperti itu dan menavigasi mereka lebih sulit?
Cara termudah adalah mengaktifkan pencatatan. Bergantung pada versi Apache, mekanisme kerjanya mungkin sedikit berubah. Tetapi sistem akan segera menyorot kepada Anda url aturan mana yang berfungsi untuk Anda dan apa yang masih perlu diperbaiki.
Anda juga dapat menentukan domain dalam aturan: ini adalah referensi untuk integrasi.
Setelah dispatcher digunakan untuk caching, permintaan dieksekusi berkali-kali lebih cepat: Anda tidak perlu pergi ke mana pun dan memeriksa, dan Anda dapat segera memberikannya kepada klien. Plus, metode ini sangat meningkatkan keamanan aplikasi Anda.
Pemalsuan Permintaan Situs Lintas - permintaan palsu.
Prinsip umum CSRF: misalkan Anda menggunakan akun Anda di situs web bank. Setelah otorisasi, Anda memiliki sesi standar dengan cookie di browser, Anda menerima email dan mengikuti tautan ke situs yang mencurigakan. Di atasnya, seorang penyerang menyematkan formulir, setelah selesai mengirim data Anda ke situs web bank.
Intinya ada di protokol HTTP. Penyerang tidak membutuhkan banyak data: permintaan ini cukup. Server bank akan melihat: permintaan telah tiba, ada cookie dan sesi, semuanya baik-baik saja. Beginilah cara kerja serangan biasa.
Apa yang dapat diberikan AEM untuk mencegah pemalsuan permintaan
Contoh klasik perlindungan adalah pembuatan "rahasia" dalam sebuah string. Saat formulir dibuat, token rahasia ini ditambahkan dari bidang tersembunyi. Jika Anda pergi ke situs penyerang, sistem akan mendeteksi tidak adanya token atau ketidakabsahannya dan akan menolak untuk mengirim data. Terkadang mereka melakukan perlindungan dari pengguna sendiri.
Sekarang Anda memiliki ajack biasa, di mana Anda tidak dapat menambahkan bidang tersembunyi. Pada tahap otorisasi, server mengembalikan cookie dengan nama dengan SCRF kepada Anda, mentransfernya ke header, mengirimkannya ke server. Jadi, Anda menandatangani permintaan.
AEM akan melakukan segalanya untuk Anda: itu akan menghasilkan kunci, token, itu akan memeriksa pengiriman formulir
Ada kasus ketika aplikasi ditulis dalam Bereaksi dan ada saat yang sulit dengan integrasi. AEM memperhitungkan situasi ini: langsung saja masuk dan tandatangani untuk verifikasi. Cocok saat menggunakan komponen dan perpustakaan yang tidak standar.
Apa lagi yang bisa dilakukan untuk melindungi sistem:
- Perpustakaan yang bertanggung jawab untuk ini. Tidak ada gunanya menambahkan sampai Anda memecahkan apa pun.
- Pada level rendah Anda dapat melihat semua "rahasia". Ini adalah semacam validasi data Anda.
- Sederhana: ada api yang sudah jadi dan Anda sudah terlindungi dari serangan jenis ini.
Serangan DDOS - serangan paling populer kedua
Tujuannya adalah untuk menguras kemampuan fisik server. Jutaan permintaan sedang dilakukan pada beberapa host. Ketika mereka menjadi banyak sekali, sistem mulai secara fisik tidak mengatasinya. Sebagai aturan, mereka menyerang dengan kuat dari beberapa sumber dan menggunakan VPN. 100% dari ini tidak diasuransikan; tapi jangan membantu mereka.
Dalam hal ini sistemnya rentan:
- Konfigurasikan sistem dengan akhiran yang salah;
- Ada banyak permintaan untuk avs, operator di publik tidak dapat meneruskannya;
- Ketika itu tidak dilarang untuk menampilkan jumlah node konten yang tidak terbatas. Secara khusus, renderer JSON, yang dapat melintasi struktur pohon di beberapa tingkatan.
- localhost : 4502 / .json dapat membuang seluruh repositori dalam format JSON.
Untuk membuat pekerjaan Anda di AEM lebih aman, fokuslah pada kemampuan pengguna tertentu.
Jangan lupa untuk memeriksa Daftar Periksa Keamanan Adobe , dan biarkan semuanya stabil dengan proyek Anda di AEM.