Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# 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
**Topics**
+ [Gambaran yang lebih besar: kontrol akses berbutir halus dan keamanan Layanan OpenSearch](#fgac-access-policies)
+ [Konsep utama](#fgac-concepts)
+ [Tentang pengguna master](#fgac-master-user)
+ [Mengaktifkan kontrol akses detail](#fgac-enabling)
+ [Mengakses OpenSearch Dasbor sebagai pengguna utama](#fgac-dashboards)
+ [Mengelola izin](#fgac-access-control)
+ [Konfigurasi yang direkomendasikan](#fgac-recommendations)
+ [Batasan](#fgac-limitations)
+ [Mengubah pengguna utama](#fgac-forget)
+ [Pengguna utama tambahan](#fgac-more-masters)
+ [Snapshot manual](#fgac-snapshots)
+ [Integrasi](#fgac-integrations)
+ [Perbedaan API REST](#fgac-rest-api)
+ [Tutorial: Konfigurasikan domain dengan pengguna master IAM dan otentikasi Amazon Cognito](fgac-iam.md)
+ [Tutorial: Konfigurasikan domain dengan database pengguna internal dan otentikasi dasar HTTP](fgac-http-auth.md)
## 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](vpc.md).
**Kebijakan akses domain**
Lapisan keamanan kedua adalah kebijakan akses domain. Setelah permintaan mencapai titik akhir domain, [kebijakan akses berbasis sumber daya](ac.md#ac-types-resource) 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.
![\[Alur autorisasi kontrol akses detail dengan domain VPC\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/images/fgac-vpc-iam.png)
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.
![\[Alur autorisasi kontrol akses detail dengan domain akses publik\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/images/fgac-public-basic.png)
### 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-baca`index1`, 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](https://opensearch.org/docs/latest/security/) 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](#fgac-more-masters).
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. *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](https://opensearch.org/docs/latest/security/access-control/permissions/) 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](https://curl.haxx.se/), yang juga mendukung AWS Signature Version 4 dengan [opsi --aws-sigv4](https://curl.se/docs/manpage.html). 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](createupdatedomains.md).
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](encryption-at-rest.md), dan [node-to-node enkripsi](ntn.md). 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**.
1. Pilih **Aktifkan kontrol akses berbutir halus**.
1. 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.
1. (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](ac.md#ac-types-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](#fgac-access-control) 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.
1. Pilih **Simpan perubahan**.
Perubahan tersebut memicu [penerapan biru/hijau](managedomains-configuration-changes.md#bg) 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\$1role
[Kontrol akses berbutir halus membutuhkan pemetaan peran.](#fgac-mapping) Jika domain Anda menggunakan [kebijakan akses berbasis identitas](ac.md#ac-types-identity), OpenSearch Layanan secara otomatis memetakan pengguna Anda ke peran baru yang disebut **default\$1role** 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\$1role](#fgac-enabling-defaultrole)** sehingga mereka dapat terus mengakses domain. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/fgac.html) |
| 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. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/fgac.html) |
| Kebijakan akses terbuka | Semua pengguna melalui internet dapat mengakses domain. | Selama periode migrasi 30 hari, semua pengguna melalui internet dapat terus mengakses domain. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/fgac.html) |
## 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](cognito-auth.md) untuk mengakses Dasbor. Jika tidak, Dasbor menampilkan halaman masuk yang tidak berfungsi. Lihat [Batasan](#fgac-limitations).
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](cognito-auth.md#cognito-auth-granular) dan [Tutorial: Konfigurasikan domain dengan pengguna master IAM dan otentikasi Amazon Cognito](fgac-iam.md).
![\[Halaman masuk Cognito\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/images/cognito-auth.png)
+ 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. Amazon Cognito dan otentikasi 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](fgac-http-auth.md).
![\[Halaman masuk autentikasi basic\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/images/basic-auth-dashboards.png)
+ Jika Anda memilih untuk menggunakan autentikasi SAML, Anda dapat masuk menggunakan kredensial dari penyedia identitas eksternal. Untuk informasi selengkapnya, lihat [Otentikasi SAMP untuk Dasbor OpenSearch](saml.md).
## Mengelola izin
Sebagaimana dicatat di [Konsep utama](#fgac-concepts), 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](#fgac-dashboards) untuk melakukan operasi ini.
![\[Halaman beranda keamanan di Dasbor\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/images/dashboards-fgac-home.png)
**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](https://en.wikipedia.org/wiki/Principle_of_least_privilege).
### 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](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-roles).
Kontrol akses detail juga mencakup sejumlah [peran yang telah ditetapkan](https://opensearch.org/docs/latest/security/access-control/users-roles/#predefined-roles). 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](#fgac-mapping) 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.](https://opensearch.org/docs/latest/security/access-control/permissions/#cluster-permissions)
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.](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#cluster-level)
#### 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.](https://opensearch.org/docs/latest/security/access-control/permissions/#index-permissions)
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.](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#index-level)
#### 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](#fgac-example).
Untuk informasi selengkapnya, lihat [Keamanan tingkat dokumen](https://opensearch.org/docs/latest/security/access-control/document-level-security/).
#### 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.](#fgac-example).
Untuk informasi selengkapnya, lihat [Keamanan tingkat lapangan](https://opensearch.org/docs/latest/security/access-control/field-level-security/).
#### 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](#fgac-example).
**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](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-users).
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](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
### 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 string pengguna pengguna ARNs, pengguna, dan Amazon Cognito di bagian Pengguna.** String pengguna Cognito berbentuk `Cognito/user-pool-id/username`.
+ Tentukan peran backend dan peran IAM ARNs di bagian peran **Backend**.
![\[Layar pemetaan peran\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/images/role-mapping-edit.png)
Anda dapat memetakan peran ke pengguna menggunakan OpenSearch Dasbor atau `_plugins/_security` operasi di REST API. Untuk informasi selengkapnya, lihat [Memetakan pengguna ke peran](https://opensearch.org/docs/latest/security/access-control/users-roles/#map-users-to-roles).
### 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](https://opensearch.org/docs/latest/security/access-control/default-action-groups/).
### 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](https://opensearch.org/docs/latest/security/multi-tenancy/tenant-index/).
**Untuk melihat penyewa Anda saat ini atau mengubah penyewa**
1. Arahkan ke OpenSearch Dasbor dan masuk.
1. **Pilih ikon pengguna Anda di kanan atas dan pilih Beralih penyewa.**
1. 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](#fgac-access-policies), 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 APIs, dan gunakan [otentikasi SAFL](saml.md) untuk mengakses Dasbor. Kelola peran kontrol akses berbutir halus menggunakan Dasbor atau REST API. | Peran IAM atau pengguna | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
``` |
| Gunakan kredensi IAM atau otentikasi dasar untuk panggilan ke file. OpenSearch APIs 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](saml.md) untuk mengakses Dasbor. Jika tidak, kelola pengguna Dasbor di database pengguna internal. | Nama pengguna dan kata sandi | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
``` |
| Gunakan kredenal IAM untuk panggilan ke OpenSearch APIs, dan gunakan Amazon Cognito untuk mengakses Dasbor. Kelola peran kontrol akses berbutir halus menggunakan Dasbor atau REST API. | Peran IAM atau pengguna | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
``` |
| Gunakan kredensil IAM untuk panggilan ke OpenSearch APIs, dan blokir sebagian besar akses ke Dasbor. Mengelola peran kontrol akses detail menggunakan API REST. | Peran IAM atau pengguna | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
},
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/_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](sql-support.md) 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](indexing.md#indexing-naming). 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](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/direct-query-s3-creating.html#direct-query-s3-prereq) 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/rumah/](https://console.aws.amazon.com/aos/home/).
1. Pilih domain Anda dan pilih **Tindakan**, **Edit konfigurasi keamanan**.
1. 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.
1. 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.
![\[Halaman pemetaan peran\]](http://docs.aws.amazon.com/id_id/opensearch-service/latest/developerguide/images/new-master-users.png)
+ 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](managedomains-snapshots.md#managedomains-snapshot-prerequisites).
Kemudian gunakan IAM role tersebut untuk mengirim permintaan yang ditandatangani ke domain, seperti yang diuraikan dalam [Mendaftarkan repositori snapshot manual](managedomains-snapshot-registerdirectory.md).
## Integrasi
Jika Anda menggunakan [AWS layanan lain](integrations.md) 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](#fgac-roles) halus, dan [petakan peran IAM ke](#fgac-mapping) 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 Anda. OpenSearch/Elasticsearch 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](https://opensearch.org/docs/latest/security/access-control/api/).
**Tip**
Jika Anda menggunakan basis data pengguna internal, Anda dapat menggunakan [curl](https://curl.haxx.se/) 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'
```