Kontrol akses berbutir halus di Layanan Amazon OpenSearch

Kontrol akses berbutir halus menawarkan cara tambahan untuk mengontrol akses ke data Anda di Layanan Amazon. OpenSearch Misalnya, bergantung pada siapa yang membuat permintaan, Anda mungkin ingin penelusuran mengembalikan hasil hanya dari satu indeks. Anda mungkin ingin menyembunyikan bidang tertentu dalam dokumen Anda atau mengecualikan dokumen tertentu sama sekali.

Kontrol akses detail menawarkan manfaat sebagai berikut:

• Kontrol akses berbasis peran

• Keamanan pada tingkat indeks, dokumen, dan bidang

• OpenSearch Dasbor multi-tenancy

• Otentikasi dasar HTTP untuk OpenSearch dan OpenSearch Dasbor

Topik

• Gambaran yang lebih besar: kontrol akses berbutir halus dan keamanan Layanan OpenSearch
• Konsep utama
• Tentang pengguna master
• Mengaktifkan kontrol akses detail
• Mengakses OpenSearch Dasbor sebagai pengguna utama
• Mengelola izin
• Konfigurasi yang direkomendasikan
• Batasan
• Mengubah pengguna utama
• Pengguna utama tambahan
• Snapshot manual
• Integrasi
• Perbedaan API REST
• Tutorial: Konfigurasikan domain dengan pengguna master IAM dan otentikasi Amazon Cognito
• Tutorial: Konfigurasikan domain dengan database pengguna internal dan otentikasi dasar HTTP

Gambaran yang lebih besar: kontrol akses berbutir halus dan keamanan Layanan OpenSearch

Keamanan Amazon OpenSearch Service memiliki tiga lapisan utama:

Jaringan

Lapisan keamanan pertama adalah jaringan, yang menentukan apakah permintaan mencapai domain OpenSearch Layanan. Jika Anda memilih Akses publik ketika Anda membuat domain, permintaan dari setiap klien yang terhubung internet dapat mencapai titik akhir domain. Jika Anda memilih Akses VPC, klien harus terhubung ke VPC (dan kelompok keamanan terkait harus mengizinkannya) untuk permintaan untuk mencapai titik akhir. Untuk informasi selengkapnya, lihat Meluncurkan domain OpenSearch Layanan Amazon Anda dalam VPC.

Kebijakan akses domain

Lapisan keamanan kedua adalah kebijakan akses domain. Setelah permintaan mencapai titik akhir domain, kebijakan akses berbasis sumber daya memungkinkan atau menyangkal akses permintaan ke URI yang diberikan. Kebijakan akses menerima atau menolak permintaan di “tepi” domain, sebelum mereka mencapai OpenSearch dirinya sendiri.

Kontrol akses berbutir halus

Lapisan keamanan ketiga dan terakhir adalah kontrol akses yang sangat baik. Setelah kebijakan akses berbasis sumber daya memungkinkan permintaan untuk mencapai titik akhir domain, kontrol akses detail mengevaluasi kredensial pengguna dan mengautentikasi pengguna atau menolak permintaan. Jika kontrol akses detail mengautentikasi pengguna, mengambil semua peran yang dipetakan ke pengguna itu dan menggunakan set lengkap izin untuk menentukan bagaimana menangani permintaan.

catatan

Jika kebijakan akses berbasis sumber daya berisi peran atau pengguna IAM, klien harus mengirim permintaan yang ditandatangani menggunakan Tanda Tangan Versi 4. AWS Dengan demikian, kebijakan akses dapat bertentangan dengan kontrol akses detail, terutama jika Anda menggunakan basis data pengguna internal dan autentikasi basic HTTP. Anda tidak dapat menandatangani permintaan dengan nama pengguna dan kata sandi serta kredensil IAM. Secara umum, jika Anda mengaktifkan kontrol akses detail, sebaiknya gunakan kebijakan akses domain yang tidak memerlukan permintaan yang ditandatangani.

Diagram berikut mengilustrasikan konfigurasi umum: domain akses VPC dengan kontrol akses berbutir halus diaktifkan, kebijakan akses berbasis IAM, dan pengguna master IAM.

Diagram berikut menggambarkan konfigurasi umum lainnya: domain akses publik dengan kontrol akses halus diaktifkan, kebijakan akses yang tidak menggunakan prinsip IAM, dan pengguna master dalam database pengguna internal.

Contoh

Pertimbangkan permintaan GET ke movies/_search?q=thor. Apakah pengguna memiliki izin untuk mencari indeks movies? Jika demikian, apakah pengguna memiliki izin untuk melihat semua dokumen di dalamnya? Haruskah respons menghilangkan atau menganonimkan bidang apa pun? Untuk pengguna utama, responsnya mungkin akan terlihat seperti ini:

{
  "hits": {
    "total": 7,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "directors": [
            "Kenneth Branagh",
            "Joss Whedon"
          ],
          "release_date": "2011-04-21T00:00:00Z",
          "genres": [
            "Action",
            "Adventure",
            "Fantasy"
          ],
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor",
          "actors": [
            "Chris Hemsworth",
            "Anthony Hopkins",
            "Natalie Portman"
          ],
          "year": 2011
        }
      },
      ...
    ]
  }
}

Jika pengguna dengan izin yang lebih terbatas mengeluarkan permintaan yang sama persis, responsnya mungkin terlihat seperti ini:

{
  "hits": {
    "total": 2,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "year": 2011,
          "release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357",
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor"
        }
      },
      ...
    ]
  }
}

Respons memiliki lebih sedikit klik dan lebih sedikit bidang untuk setiap klik. Juga, bidang release_date dianonimkan. Jika pengguna tanpa izin membuat permintaan yang sama, klaster mengembalikan kesalahan:

{
  "error": {
    "root_cause": [{
      "type": "security_exception",
      "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
    }],
    "type": "security_exception",
    "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
  },
  "status": 403
}

Jika pengguna memberikan kredensial yang tidak valid, klaster mengembalikan pengecualian Unauthorized.

Konsep utama

Saat Anda memulai dengan kontrol akses berbutir halus, pertimbangkan konsep-konsep berikut:

• Peran — Cara inti menggunakan kontrol akses berbutir halus. Dalam hal ini, peran berbeda dari peran IAM. Peran berisi kombinasi izin: klaster-lebar, indeks spesifik, tingkat dokumen, dan tingkat bidang.

• Pemetaan — Setelah mengonfigurasi peran, Anda memetakannya ke satu atau beberapa pengguna. Misalnya, Anda dapat memetakan tiga peran ke satu pengguna: satu peran yang menyediakan akses ke Dasbor, satu yang menyediakan akses hanya-bacaindex1, dan satu yang menyediakan akses tulis. index2 Atau Anda dapat menyertakan semua izin tersebut dalam satu peran.

• Pengguna — Orang atau aplikasi yang membuat permintaan ke OpenSearch cluster. Pengguna memiliki kredensial—baik kunci akses IAM atau nama pengguna dan kata sandi—yang mereka tentukan saat mereka membuat permintaan.

Tentang pengguna master

Pengguna utama di OpenSearch Layanan adalah kombinasi nama pengguna dan kata sandi, atau prinsipal IAM, yang memiliki izin penuh ke cluster yang mendasarinya OpenSearch. Seorang pengguna dianggap sebagai pengguna utama jika mereka memiliki semua akses ke OpenSearch cluster bersama dengan kemampuan untuk membuat pengguna internal, peran, dan pemetaan peran dalam OpenSearch Dasbor.

Pengguna master yang dibuat di konsol OpenSearch Layanan atau melalui CLI secara otomatis dipetakan ke dua peran yang telah ditentukan:

• all_access— Menyediakan akses penuh ke semua operasi di seluruh cluster, izin untuk menulis ke semua indeks cluster, dan izin untuk menulis ke semua penyewa.

• security_manager— Menyediakan akses ke plugin Keamanan dan manajemen pengguna dan izin.

Dengan dua peran ini, pengguna mendapatkan akses ke tab Keamanan di OpenSearch Dasbor, tempat mereka dapat mengelola pengguna dan izin. Jika Anda membuat pengguna internal lain dan hanya memetakannya ke all_access peran, pengguna tidak memiliki akses ke tab Keamanan. Anda dapat membuat pengguna master tambahan dengan memetakannya secara eksplisit ke peran dan peran. all_access security_manager Untuk petunjuk, lihat Pengguna utama tambahan.

Saat Anda membuat pengguna master untuk domain Anda, Anda dapat menentukan salah satu prinsipal IAM yang ada, atau membuat pengguna master dalam database pengguna internal. Pertimbangkan hal berikut saat memutuskan mana yang akan digunakan:

• Prinsipal IAM — Jika Anda memilih prinsipal IAM untuk pengguna master Anda, semua permintaan ke klaster harus ditandatangani menggunakan AWS Signature Version 4.

  OpenSearch Layanan tidak mempertimbangkan izin kepala sekolah IAM apa pun. Pengguna atau peran IAM berfungsi murni untuk otentikasi. Kebijakan tentang pengguna atau peran tersebut tidak ada kaitannya dengan otorisasi pengguna utama. Otorisasi ditangani melalui berbagai izin di plugin Keamanan. OpenSearch

  Misalnya, Anda dapat menetapkan nol izin IAM ke prinsipal IAM, dan selama mesin atau orang tersebut dapat mengautentikasi ke pengguna atau peran tersebut, mereka memiliki kekuatan pengguna utama di Layanan. OpenSearch

  Kami merekomendasikan IAM jika Anda ingin menggunakan pengguna yang sama di beberapa cluster, jika Anda ingin menggunakan Amazon Cognito untuk mengakses Dasbor, atau jika Anda OpenSearch memiliki klien yang mendukung penandatanganan Signature Version 4.

• Database pengguna internal — Jika Anda membuat master di database pengguna internal (dengan kombinasi nama pengguna dan kata sandi), Anda dapat menggunakan otentikasi dasar HTTP (serta kredenal IAM) untuk membuat permintaan ke cluster. Sebagian besar klien mendukung otentikasi dasar, termasuk curl, yang juga mendukung AWS Signature Version 4 dengan opsi --aws-sigv4. Database pengguna internal disimpan dalam OpenSearch indeks, sehingga Anda tidak dapat membagikannya dengan cluster lain.

  Kami merekomendasikan database pengguna internal jika Anda tidak perlu menggunakan kembali pengguna di beberapa cluster, jika Anda ingin menggunakan otentikasi dasar HTTP untuk mengakses Dasbor (bukan Amazon Cognito), atau jika Anda memiliki klien yang hanya mendukung otentikasi dasar. Database pengguna internal adalah cara paling sederhana untuk memulai dengan OpenSearch Layanan.

Mengaktifkan kontrol akses detail

Aktifkan kontrol akses berbutir halus menggunakan konsol, AWS CLI, atau API konfigurasi. Untuk langkah, lihat Membuat dan mengelola domain OpenSearch Layanan Amazon.

Kontrol akses berbutir halus memerlukan OpenSearch atau Elasticsearch 6.7 atau yang lebih baru. Ini juga membutuhkan HTTPS untuk semua lalu lintas ke domain, Enkripsi data saat istirahat, dan node-to-node enkripsi. Bergantung pada cara Anda mengonfigurasi fitur lanjutan dari kontrol akses berbutir halus, pemrosesan tambahan permintaan Anda mungkin memerlukan sumber daya komputasi dan memori pada node data individual. Setelah Anda mengaktifkan kontrol akses detail, Anda tidak dapat menonaktifkannya.

Mengaktifkan kontrol akses berbutir halus pada domain yang ada

Anda dapat mengaktifkan kontrol akses berbutir halus pada domain yang ada yang berjalan OpenSearch atau Elasticsearch 6.7 atau yang lebih baru.

Untuk mengaktifkan kontrol akses berbutir halus pada domain yang ada (konsol)

1. Pilih domain Anda dan pilih Tindakan dan Edit konfigurasi keamanan.

2. Pilih Aktifkan kontrol akses berbutir halus.

3. Pilih cara membuat pengguna master:

   • Jika Anda ingin menggunakan IAM untuk manajemen pengguna, pilih Setel IAM ARN sebagai pengguna utama dan tentukan ARN untuk peran IAM.

   • Jika Anda ingin menggunakan database pengguna internal, pilih Buat pengguna utama dan tentukan nama pengguna dan kata sandi.

4. (Opsional) Pilih Aktifkan periode migrasi untuk kebijakan akses berbasis Buka/IP. Pengaturan ini memungkinkan periode transisi 30 hari di mana pengguna Anda yang ada dapat terus mengakses domain tanpa gangguan, dan kebijakan akses terbuka dan berbasis IP yang ada akan terus bekerja dengan domain Anda. Selama periode migrasi ini, kami menyarankan agar administrator membuat peran yang diperlukan dan memetakannya ke pengguna untuk domain. Jika Anda menggunakan kebijakan berbasis identitas alih-alih kebijakan akses terbuka atau berbasis IP, Anda dapat menonaktifkan setelan ini.

   Anda juga perlu memperbarui klien Anda untuk bekerja dengan kontrol akses berbutir halus selama periode migrasi. Misalnya, jika Anda memetakan peran IAM dengan kontrol akses berbutir halus, Anda harus memperbarui klien Anda untuk mulai menandatangani permintaan dengan AWS Signature Version 4. Jika Anda mengonfigurasi otentikasi dasar HTTP dengan kontrol akses berbutir halus, Anda harus memperbarui klien Anda untuk memberikan kredensyal otentikasi dasar yang sesuai dalam permintaan.

   Selama periode migrasi, pengguna yang mengakses titik akhir OpenSearch Dasbor untuk domain akan langsung mendarat di halaman Discover, bukan halaman login. Administrator dan pengguna master dapat memilih Login untuk masuk dengan kredensi admin dan mengonfigurasi pemetaan peran.

   penting

   OpenSearch Layanan secara otomatis menonaktifkan periode migrasi setelah 30 hari. Kami menyarankan untuk mengakhirinya segera setelah Anda membuat peran yang diperlukan dan memetakannya kepada pengguna. Setelah periode migrasi berakhir, Anda tidak dapat mengaktifkannya kembali.

5. Pilih Simpan perubahan.

Perubahan tersebut memicu penerapan biru/hijau di mana kesehatan cluster menjadi merah, tetapi semua operasi cluster tetap tidak terpengaruh.

Untuk mengaktifkan kontrol akses berbutir halus pada domain yang ada (CLI)

Setel AnonymousAuthEnabled true untuk mengaktifkan periode migrasi dengan kontrol akses berbutir halus:

aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \
      --advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}'

Tentang default_role

Kontrol akses berbutir halus membutuhkan pemetaan peran. Jika domain Anda menggunakan kebijakan akses berbasis identitas, OpenSearch Layanan secara otomatis memetakan pengguna Anda ke peran baru yang disebut default_role untuk membantu Anda memigrasi pengguna yang sudah ada dengan benar. Pemetaan sementara ini memastikan bahwa pengguna Anda masih dapat berhasil mengirim permintaan GET dan PUT yang ditandatangani oleh IAM hingga Anda membuat pemetaan peran Anda sendiri.

Peran tersebut tidak menambahkan kerentanan atau kekurangan keamanan apa pun ke domain OpenSearch Layanan Anda. Sebaiknya hapus peran default segera setelah Anda mengatur peran Anda sendiri dan memetakannya sesuai dengan itu.

Skenario migrasi

Tabel berikut menjelaskan perilaku untuk setiap metode otentikasi sebelum dan sesudah mengaktifkan kontrol akses berbutir halus pada domain yang ada, dan langkah-langkah yang harus diambil administrator untuk memetakan pengguna mereka dengan benar ke peran:

Metode otentikasi	Sebelum mengaktifkan kontrol akses berbutir halus	Setelah mengaktifkan kontrol akses berbutir halus	Tugas administrator
Kebijakan berbasis identitas	Semua pengguna yang memenuhi kebijakan IAM dapat mengakses domain.	Anda tidak perlu mengaktifkan periode migrasi. OpenSearch Layanan secara otomatis memetakan semua pengguna yang memenuhi kebijakan IAM ke default_role sehingga mereka dapat terus mengakses domain.	Buat pemetaan peran khusus di domain. Hapus default_role.
Kebijakan berbasis IP	Semua pengguna dari alamat IP yang diizinkan atau blok CIDR dapat mengakses domain.	Selama periode migrasi 30 hari, semua pengguna dari alamat IP yang diizinkan atau blok CIDR dapat terus mengakses domain.	Buat pemetaan peran khusus di domain. Perbarui klien Anda untuk menyediakan kredensyal otentikasi dasar atau kredensyal IAM, tergantung pada konfigurasi pemetaan peran Anda. Nonaktifkan periode migrasi. Pengguna dari alamat IP yang diizinkan atau blok CIDR mengirim permintaan tanpa otentikasi dasar atau kredensyal IAM akan kehilangan akses ke domain.
Kebijakan akses terbuka	Semua pengguna melalui internet dapat mengakses domain.	Selama periode migrasi 30 hari, semua pengguna melalui internet dapat terus mengakses domain.	Buat pemetaan peran di domain. Perbarui klien Anda untuk menyediakan kredensyal otentikasi dasar atau kredensyal IAM, tergantung pada konfigurasi pemetaan peran Anda. Nonaktifkan periode migrasi. Pengguna yang mengirim permintaan tanpa otentikasi dasar atau kredensil IAM akan kehilangan akses ke domain.

Mengakses OpenSearch Dasbor sebagai pengguna utama

Kontrol akses berbutir halus memiliki plugin OpenSearch Dasbor yang menyederhanakan tugas manajemen. Anda dapat menggunakan Dasbor untuk mengelola pengguna, peran, pemetaan, grup tindakan, dan penyewa. Namun, halaman login OpenSearch Dasbor dan metode otentikasi yang mendasarinya berbeda, tergantung pada cara Anda mengelola pengguna dan mengonfigurasi domain Anda.

• Jika Anda ingin menggunakan IAM untuk manajemen pengguna, gunakan Mengonfigurasi otentikasi Amazon Cognito untuk Dasbor OpenSearch untuk mengakses Dasbor. Jika tidak, Dasbor menampilkan halaman masuk yang tidak berfungsi. Lihat Batasan.

  Dengan autentikasi Amazon Cognito, salah satu peran diasumsikan dari kolam identitas harus sesuai dengan IAM role yang Anda tentukan untuk pengguna master. Untuk informasi lebih lanjut tentang konfigurasi ini, lihat (Opsional) Mengonfigurasi akses terperinci dan Tutorial: Konfigurasikan domain dengan pengguna master IAM dan otentikasi Amazon Cognito.

  

• Jika Anda memilih untuk menggunakan basis data pengguna internal, Anda dapat masuk ke Dasbor dengan nama pengguna dan kata sandi utama Anda. Anda harus mengakses Dasbor melalui HTTPS. Otentikasi Amazon Cognito dan SAM untuk Dasbor keduanya menggantikan layar login ini.

  Untuk informasi lebih lanjut tentang konfigurasi ini, lihat Tutorial: Konfigurasikan domain dengan database pengguna internal dan otentikasi dasar HTTP.

  

• Jika Anda memilih untuk menggunakan autentikasi SAML, Anda dapat masuk menggunakan kredensial dari penyedia identitas eksternal. Untuk informasi selengkapnya, lihat SAMLotentikasi untuk Dasbor OpenSearch .

Mengelola izin

Sebagaimana dicatat di Konsep utama, Anda mengelola izin kontrol akses detail menggunakan peran, pengguna, dan pemetaan. Bagian ini menjelaskan cara membuat dan menerapkan sumber daya tersebut. Kami menyarankan Anda masuk ke Dasbor sebagai pengguna utama untuk melakukan operasi ini.

catatan

Izin yang Anda pilih untuk diberikan kepada pengguna Anda sangat bervariasi berdasarkan kasus penggunaan. Kami tidak dapat secara layak mencakup semua skenario dalam dokumentasi ini. Saat Anda menentukan izin mana yang akan diberikan kepada pengguna Anda, pastikan untuk mereferensikan izin OpenSearch klaster dan indeks yang disebutkan di bagian berikut, dan selalu ikuti prinsip hak istimewa paling sedikit.

Membuat peran

Anda dapat membuat peran baru untuk kontrol akses berbutir halus menggunakan OpenSearch Dasbor atau _plugins/_security operasi di REST API. Untuk informasi selengkapnya, lihat Membuat peran.

Kontrol akses detail juga mencakup sejumlah peran yang telah ditetapkan. Klien seperti OpenSearch Dasbor dan Logstash membuat berbagai macam permintaan OpenSearch, yang dapat menyulitkan untuk membuat peran secara manual dengan set izin minimum. Misalnya, peran opensearch_dashboards_user menyertakan izin yang pengguna perlu bekerja dengan pola indeks, visualisasi, dashboard, dan penyewa. Kami merekomendasikan untuk memetakannya ke setiap pengguna atau peran backend yang mengakses Dasbor, bersama dengan peran tambahan yang memungkinkan akses ke indeks lain.

Amazon OpenSearch Service tidak menawarkan OpenSearch peran berikut:

• observability_full_access

• observability_read_access

• reports_read_access

• reports_full_access

Amazon OpenSearch Service menawarkan beberapa peran yang tidak tersedia dengan OpenSearch:

• ultrawarm_manager

• ml_full_access

• cold_manager

• notifications_full_access

• notifications_read_access

Keamanan tingkat klaster

Izin tingkat klaster termasuk kemampuan untuk membuat permintaan yang luas seperti _mget, _msearch, dan _bulk, memantau kesehatan, mengambil snapshot, dan banyak lagi. Kelola izin ini menggunakan bagian Izin cluster saat membuat peran. Untuk daftar lengkap izin tingkat klaster, lihat Izin klaster.

Alih-alih izin individual, Anda sering dapat mencapai postur keamanan yang Anda inginkan menggunakan kombinasi grup tindakan default. Untuk daftar grup aksi tingkat klaster, lihat Tingkat klaster.

Keamanan tingkat indeks

Izin tingkat indeks termasuk kemampuan untuk membuat indeks baru, indeks pencarian, membaca dan menulis dokumen, menghapus dokumen, mengelola alias, dan banyak lagi. Kelola izin ini menggunakan bagian Izin Indeks saat membuat peran. Untuk daftar lengkap izin tingkat indeks, lihat Izin indeks.

Alih-alih izin individual, Anda sering dapat mencapai postur keamanan yang Anda inginkan menggunakan kombinasi grup tindakan default. Untuk daftar grup tindakan tingkat indeks, lihat Tingkat indeks.

Keamanan tingkat dokumen

Keamanan tingkat dokumen memungkinkan Anda membatasi dokumen mana dalam indeks yang dapat dilihat pengguna. Saat membuat peran, tentukan pola indeks dan OpenSearch kueri. Setiap pengguna yang Anda petakan ke peran tersebut dapat melihat hanya dokumen yang cocok dengan kueri. Keamanan tingkat dokumen mempengaruhi jumlah klik yang Anda terima saat Anda mencari.

Untuk informasi selengkapnya, lihat Keamanan tingkat dokumen.

Keamanan tingkat bidang

Keamanan tingkat bidang memungkinkan Anda mengontrol bidang dokumen mana yang dapat dilihat pengguna. Saat membuat peran, tambahkan daftar bidang untuk disertakan atau dikecualikan. Jika Anda menyertakan bidang, setiap pengguna yang Anda petakan ke peran tersebut hanya dapat melihat bidang tersebut. Jika Anda mengecualikan bidang, mereka dapat melihat semua bidang kecuali yang dikecualikan. Keamanan tingkat bidang memengaruhi jumlah bidang yang disertakan dalam klik saat Anda mencari..

Untuk informasi selengkapnya, lihat Keamanan tingkat lapangan.

Penyamaran bidang

Penyamaran bidang adalah alternatif untuk keamanan tingkat bidang yang memungkinkan Anda menganonimkan data di bidang daripada menghapusnya sama sekali. Saat membuat peran, tambahkan daftar bidang untuk disamarkan. Kolom penyamaran memengaruhi apakah Anda dapat melihat isi dari suatu bidang saat mencari.

Tip

Jika Anda menerapkan masking standar ke bidang, OpenSearch Layanan menggunakan hash acak yang aman yang dapat menyebabkan hasil agregasi yang tidak akurat. Untuk melakukan agregasi pada bidang yang disamarkan, gunakan penyamaran berbasis pola sebagai gantinya.

Membuat pengguna

Jika Anda mengaktifkan database pengguna internal, Anda dapat membuat pengguna menggunakan OpenSearch Dasbor atau _plugins/_security operasi di REST API. Untuk informasi selengkapnya, lihat Membuat pengguna.

Jika Anda memilih IAM untuk pengguna master Anda, abaikan bagian Dasbor ini. Buat peran IAM sebagai gantinya. Untuk informasi lebih lanjut, lihat Panduan Pengguna IAM.

Memetakan peran untuk pengguna

Pemetaan peran adalah aspek yang paling penting dari kontrol akses detail. Kontrol akses detail memiliki beberapa peran yang telah ditetapkan untuk membantu Anda memulai, tetapi kecuali jika Anda memetakan peran untuk pengguna, setiap permintaan ke klaster berakhir dengan kesalahan izin.

Peran backend dapat membantu menyederhanakan proses pemetaan peran. Daripada memetakan peran yang sama ke 100 pengguna individu, Anda dapat memetakan peran tersebut ke peran backend tunggal yang dibagikan oleh 100 pengguna. Peran backend dapat berupa peran IAM atau string arbitrer.

• Tentukan pengguna, ARN pengguna, dan string pengguna Amazon Cognito di bagian Pengguna. String pengguna Cognito berbentuk Cognito/user-pool-id/username.

• Tentukan peran backend dan ARN peran IAM di bagian peran Backend.

Anda dapat memetakan peran ke pengguna menggunakan OpenSearch Dasbor atau _plugins/_security operasi di REST API. Untuk informasi selengkapnya, lihat Memetakan pengguna ke peran.

Membuat grup tindakan

Grup tindakan adalah kumpulan izin yang dapat Anda gunakan kembali di sumber daya yang berbeda. Anda dapat membuat grup tindakan baru menggunakan OpenSearch Dasbor atau _plugins/_security operasi di REST API, meskipun grup tindakan default cukup untuk sebagian besar kasus penggunaan. Untuk informasi selengkapnya tentang grup tindakan default, lihat Grup tindakan default.

OpenSearch Dasbor multi-tenancy

Penyewa adalah ruang untuk menyimpan pola indeks, visualisasi, dasbor, dan objek Dasbor lainnya. Dashboard multi-tenancy memungkinkan Anda berbagi pekerjaan dengan aman dengan pengguna Dasbor lain (atau menjaganya tetap pribadi) dan mengonfigurasi penyewa secara dinamis. Anda dapat mengontrol peran yang memiliki akses ke penyewa dan apakah peran tersebut telah membaca atau menulis akses. Penyewa global adalah default. Untuk mempelajari lebih lanjut, lihat OpenSearch Dasbor multi-tenancy.

Untuk melihat penyewa Anda saat ini atau mengubah penyewa

1. Arahkan ke OpenSearch Dasbor dan masuk.

2. Pilih ikon pengguna Anda di kanan atas dan pilih Beralih penyewa.

3. Verifikasi penyewa Anda sebelum membuat visualisasi atau dashboard. Jika Anda ingin berbagi pekerjaan Anda dengan semua pengguna Dasbor lainnya, pilih Global. Untuk membagikan pekerjaan Anda dengan subset pengguna Dasbor, pilih penyewa bersama yang berbeda. Jika tidak, pilih Privat.

catatan

OpenSearch Dasbor mempertahankan indeks terpisah untuk setiap penyewa, dan membuat template indeks yang disebut. tenant_template Jangan menghapus atau memodifikasi tenant_template indeks, karena dapat menyebabkan OpenSearch Dasbor tidak berfungsi jika pemetaan indeks penyewa salah dikonfigurasi.

Konfigurasi yang direkomendasikan

Karena kontrol akses detail berinteraksi dengan fitur keamanan lainnya, kami merekomendasikan beberapa konfigurasi kontrol akses detail yang bekerja dengan baik untuk sebagian besar kasus penggunaan.

Deskripsi	Pengguna utama	Kebijakan akses domain
Gunakan kredensyal IAM untuk panggilan ke OpenSearch API, dan gunakan otentikasi SAFL untuk mengakses Dasbor. Kelola peran kontrol akses berbutir halus menggunakan Dasbor atau REST API.	Peran IAM atau pengguna	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Gunakan kredenal IAM atau otentikasi dasar untuk panggilan ke API. OpenSearch Kelola peran kontrol akses berbutir halus menggunakan Dasbor atau REST API. Konfigurasi ini menawarkan banyak fleksibilitas, terutama jika Anda memiliki OpenSearch klien yang hanya mendukung otentikasi dasar. Jika Anda memiliki penyedia identitas yang sudah ada, gunakan otentikasi SAM untuk mengakses Dasbor. Jika tidak, kelola pengguna Dasbor di database pengguna internal.	Nama pengguna dan kata sandi	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Gunakan kredenal IAM untuk panggilan ke OpenSearch API, dan gunakan Amazon Cognito untuk mengakses Dasbor. Kelola peran kontrol akses berbutir halus menggunakan Dasbor atau REST API.	Peran IAM atau pengguna	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Gunakan kredenal IAM untuk panggilan ke OpenSearch API, dan blokir sebagian besar akses ke Dasbor. Mengelola peran kontrol akses detail menggunakan API REST.	Peran IAM atau pengguna	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/_dashboards*" } ] }

Batasan

Kontrol akses detail memiliki beberapa keterbatasan penting:

• Aspek hosts dari pemetaan peran, yang memetakan peran ke nama host atau alamat IP, tidak berfungsi jika domain berada dalam VPC. Anda masih dapat memetakan peran untuk pengguna dan peran backend.

• Jika Anda memilih IAM untuk pengguna master dan tidak mengaktifkan autentikasi Amazon Cognito atau SAFL, Dasbor akan menampilkan halaman login yang tidak berfungsi.

• Jika Anda memilih IAM untuk pengguna utama, Anda masih dapat membuat pengguna dalam basis data pengguna internal. Karena autentikasi basic HTTP tidak diaktifkan pada konfigurasi ini, namun, setiap permintaan ditandatangani dengan kredensial pengguna tersebut ditolak.

• Jika Anda menggunakan SQL untuk kueri indeks yang Anda tidak memiliki aksesnya, Anda menerima kesalahn "tidak ada izin". Jika indeks tidak ada, Anda menerima kesalahan “indeks tersebut tidak ada”. Perbedaan pesan kesalahan ini berarti Anda dapat mengonfirmasi keberadaan indeks jika Anda menebak namanya.

  Untuk meminimalkan masalah ini, jangan sertakan informasi sensitif dalam nama indeks. Untuk menolak semua akses ke SQL, tambahkan elemen berikut ke kebijakan akses domain Anda:

  {
    "Effect": "Deny",
    "Principal": {
      "AWS": [
        "*"
      ]
    },
    "Action": [
      "es:*"
    ],
    "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql"
  }

• Jika versi domain Anda 2.3 atau lebih tinggi dan Anda mengaktifkan kontrol akses berbutir halus, pengaturan max_clause_count ke 1 menyebabkan masalah dengan domain Anda. Sebaiknya atur akun ini ke angka yang lebih tinggi.

• Jika Anda mengaktifkan kontrol akses berbutir halus di domain di mana kontrol akses berbutir halus tidak disiapkan, untuk sumber data yang dibuat untuk kueri langsung, Anda perlu mengatur sendiri peran kontrol akses berbutir halus. Untuk informasi selengkapnya tentang cara mengatur peran akses berbutir halus, lihat Membuat integrasi sumber data OpenSearch Layanan Amazon dengan Amazon S3.

Mengubah pengguna utama

Jika Anda lupa rincian pengguna utama, Anda dapat mengonfigurasi ulang menggunakan konsol, AWS CLI, atau API konfigurasi.

Untuk mengubah pengguna utama (konsol)

1. Arahkan ke konsol OpenSearch Layanan Amazon di https://console.aws.amazon.com/aos/home/.

2. Pilih domain Anda dan pilih Tindakan, Edit konfigurasi keamanan.

3. Pilih salah satu Set IAM ARN sebagai pengguna master atau Buat pengguna master.

   • Jika sebelumnya Anda menggunakan pengguna utama IAM, kontrol akses detail memetakan ulang peran all_access ke ARN IAM baru yang Anda tentukan.

   • Jika Anda sebelumnya menggunakan basis data pengguna internal, kontrol akses detail menciptakan pengguna utama baru. Anda dapat menggunakan pengguna utama baru untuk menghapus yang lama.

   • Beralih dari basis data pengguna internal untuk pengguna utama IAM tidak menghapus pengguna mana pun dari basis data pengguna internal. Sebaliknya, itu hanya menonaktifkan autentikasi basic HTTP. Hapus pengguna secara manual dari basis data pengguna internal, atau menyimpannya jika Anda mungkin perlu mengaktifkan kembali autentikasi basic HTTP.

4. Pilih Simpan perubahan.

Pengguna utama tambahan

Anda menetapkan pengguna utama ketika Anda membuat domain, tetapi jika Anda ingin, Anda dapat menggunakan pengguna utama ini untuk membuat pengguna utama tambahan. Anda memiliki dua opsi: OpenSearch Dasbor atau REST API.

• Di Dasbor, pilih Keamanan, Peran, lalu petakan pengguna master baru ke security_manager peran all_access dan.

  

• Untuk menggunakan API REST, kirim permintaan berikut:

  PUT _plugins/_security/api/rolesmapping/all_access
  {
    "backend_roles": [
      "arn:aws:iam::123456789012:role/fourth-master-user"
    ],
    "hosts": [],
    "users": [
      "master-user",
      "second-master-user",
      "arn:aws:iam::123456789012:user/third-master-user"
    ]
  }

  PUT _plugins/_security/api/rolesmapping/security_manager
  {
    "backend_roles": [
      "arn:aws:iam::123456789012:role/fourth-master-user"
    ],
    "hosts": [],
    "users": [
      "master-user",
      "second-master-user",
      "arn:aws:iam::123456789012:user/third-master-user"
    ]
  }

  Permintaan ini menggantikan pemetaan peran saat ini, jadi lakukan permintaan GET pertama sehingga Anda dapat menyertakan semua peran saat ini di permintaan PUT. REST API sangat berguna jika Anda tidak dapat mengakses Dasbor dan ingin memetakan peran IAM dari Amazon Cognito ke peran tersebut. all_access

Snapshot manual

Kontrol akses detail memperkenalkan beberapa komplikasi tambahan dengan mengambil snapshot manual. Untuk mendaftarkan repositori snapshot — bahkan jika Anda menggunakan autentikasi basic HTTP untuk semua tujuan lain—Anda harus memetakan peran manage_snapshots ke IAM role yang memiliki peran izin iam:PassRole untuk mengasumsikan TheSnapshotRole, seperti yang didefinisikan dalam Prasyarat.

Kemudian gunakan IAM role tersebut untuk mengirim permintaan yang ditandatangani ke domain, seperti yang diuraikan dalam Mendaftarkan repositori snapshot manual.

Integrasi

Jika Anda menggunakan AWS layanan lain dengan OpenSearch Layanan, Anda harus memberikan peran IAM untuk layanan tersebut dengan izin yang sesuai. Misalnya, aliran pengiriman Firehose sering menggunakan peran IAM yang disebut. firehose_delivery_role Di Dasbor, buat peran untuk kontrol akses berbutir halus, dan petakan peran IAM ke sana. Dalam kasus ini, peran baru memerlukan izin berikut:

{
  "cluster_permissions": [
    "cluster_composite_ops",
    "cluster_monitor"
  ],
  "index_permissions": [{
    "index_patterns": [
      "firehose-index*"
    ],
    "allowed_actions": [
      "create_index",
      "manage",
      "crud"
    ]
  }]
}

Izin bervariasi berdasarkan tindakan yang dilakukan setiap layanan. AWS IoT Aturan atau AWS Lambda fungsi yang mengindeks data kemungkinan memerlukan izin serupa dengan Firehose, sedangkan fungsi Lambda yang hanya melakukan penelusuran dapat menggunakan set yang lebih terbatas.

Perbedaan API REST

REST API kontrol akses berbutir halus sedikit berbeda tergantung pada versi /Elasticsearch Anda OpenSearch. Sebelum membuat permintaan PUT, buat permintaan GET untuk memverifikasi isi permintaan yang diharapkan. Misalnya, permintaan GET ke _plugins/_security/api/user mengembalikan semua pengguna, yang kemudian dapat diubah dan digunakan untuk membuat permintaan PUT yang valid.

Pada Elasticsearch 6.X, permintaan untuk membuat pengguna terlihat seperti ini:

PUT _opendistro/_security/api/user/new-user
{
  "password": "some-password",
  "roles": ["new-backend-role"]
}

Pada OpenSearch atau Elasticsearch 7.x, permintaan terlihat seperti ini (ubah _plugins menjadi _opendistro jika menggunakan Elasticsearch):

PUT _plugins/_security/api/user/new-user
{
  "password": "some-password",
  "backend_roles": ["new-backend-role"]
}

Selanjutnya, penyewa adalah properti peran dalam Elasticsearch 6.X:

GET _opendistro/_security/api/roles/all_access

{
  "all_access": {
    "cluster": ["UNLIMITED"],
    "tenants": {
      "admin_tenant": "RW"
    },
    "indices": {
      "*": {
        "*": ["UNLIMITED"]
      }
    },
    "readonly": "true"
  }
}

Di OpenSearch dan Elasticsearch 7.x, mereka adalah objek dengan URI mereka sendiri (ubah _plugins ke _opendistro if menggunakan Elasticsearch)::

GET _plugins/_security/api/tenants

{
  "global_tenant": {
    "reserved": true,
    "hidden": false,
    "description": "Global tenant",
    "static": false
  }
}

Untuk dokumentasi tentang OpenSearch REST API, lihat referensi API plugin Keamanan.

Tip

Jika Anda menggunakan basis data pengguna internal, Anda dapat menggunakan curl untuk membuat permintaan dan menguji domain Anda. Coba perintah contoh berikut:

curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_search'
curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_plugins/_security/api/user'