Tipe kebijakan Ketika kebijakan bertabrakan Referensi elemen kebijakan Pilihan lanjutan dan pertimbangan API Mengonfigurasi kebijakan akses Contoh kebijakan tambahan

Identity and Access Management di Amazon OpenSearch Service

Amazon OpenSearch Service menawarkan beberapa cara untuk mengontrol akses ke domain Anda. Topik ini mencakup berbagai tipe kebijakan, bagaimana kebijakan berinteraksi satu sama lain, dan cara membuat kebijakan kustom Anda sendiri.

penting

Dukungan VPC memperkenalkan beberapa pertimbangan tambahan untuk OpenSearch kontrol akses Layanan. Untuk informasi selengkapnya, lihat Tentang kebijakan akses pada domain VPC.

Tipe kebijakan

OpenSearch Layanan mendukung tiga jenis kebijakan akses:

Kebijakan berbasis sumber daya
Kebijakan berbasis identitas
Kebijakan berbasis IP

Kebijakan berbasis sumber daya

Anda menambahkan kebijakan berbasis sumber daya, sering disebut kebijakan akses domain, ketika Anda membuat domain. Kebijakan ini menentukan tindakan mana yang dapat dilakukan prinsipal pada subsumber daya domain (dengan pengecualian pencarian lintas klaster). Subresource termasuk OpenSearch indeks dan. APIs Elemen Utama menentukan akun, pengguna, atau peran yang diizinkan akses. Elemen Sumber Daya menentukan sub sumber daya mana utama ini dapat akses.

Misalnya, kebijakan berbasis sumber daya berikut memberikan akses test-user penuh (es:*) ke subsumber daya pada: test-domain


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:*"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

Dua pertimbangan penting berlaku untuk kebijakan ini:

Hak istimewa ini hanya berlaku untuk domain ini. Kecuali Anda membuat kebijakan serupa di domain lain, test-user hanya dapat mengakses test-domain.
Jejak /* di elemen Resource adalah signifikan dan menunjukkan bahwa kebijakan berbasis sumber daya hanya berlaku untuk sub sumber daya domain, bukan domain itu sendiri. Dalam kebijakan berbasis sumber daya, aksi es:* setara dengan es:ESHttp*.

Misalnya, test-user dapat membuat permintaan terhadap indeks (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index), namun tidak dapat memperbarui konfigurasi domain (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config). Perhatikan perbedaan antara dua titik akhir. Mengakses API konfigurasi memerlukan kebijakan berbasis identitas.

Anda dapat menentukan nama indeks sebagian dengan menambahkan wildcard. Contoh ini mengidentifikasi indeks apa pun yang dimulai dengan: commerce


arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*

Dalam hal ini, wildcard berarti test-user dapat membuat permintaan ke indeks di dalamnya test-domain yang memiliki nama yang dimulai. commerce

Untuk lebih membatasi test-user, Anda dapat menerapkan kebijakan berikut:


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttpGet"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search"
    }
  ]
}

Sekarang hanya test-user dapat melakukan satu operasi: pencarian terhadap commerce-data indeks. Semua indeks lain dalam domain tidak dapat diakses, dan tanpa izin untuk menggunakan es:ESHttpPut atau es:ESHttpPost tindakan, tidak test-user dapat menambahkan atau memodifikasi dokumen.

Selanjutnya, Anda dapat memutuskan untuk mengonfigurasi peran bagi pengguna daya. Kebijakan ini memberikan power-user-role akses ke metode HTTP GET dan PUT untuk semua yang URIs ada di indeks:


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:role/power-user-role"
        ]
      },
      "Action": [
        "es:ESHttpGet",
        "es:ESHttpPut"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*"
    }
  ]
}

Jika domain Anda berada di VPC atau menggunakan kontrol akses detail, Anda dapat menggunakan kebijakan akses domain terbuka. Jika tidak, kebijakan akses domain Anda harus berisi beberapa pembatasan, baik berdasarkan prinsip atau alamat IP.

Untuk informasi tentang semua tindakan yang tersedia, lihat Referensi elemen kebijakan. Untuk kontrol yang jauh lebih rinci atas data Anda, gunakan kebijakan akses domain terbuka dengan kontrol akses detail.

Kebijakan berbasis identitas

Tidak seperti kebijakan berbasis sumber daya, yang merupakan bagian dari setiap domain OpenSearch Layanan, Anda melampirkan kebijakan berbasis identitas kepada pengguna atau peran yang menggunakan layanan (IAM). AWS Identity and Access Management Sama seperti kebijakan berbasis sumber daya, kebijakan berbasis identitas menentukan siapa yang dapat mengakses layanan, tindakan mana yang dapat mereka lakukan, dan jika berlaku, sumber daya tempat mereka dapat melakukan tindakan tersebut.

Meskipun kebijakan tentu tidak harus, kebijakan berbasis identitas cenderung lebih generik. Kebijakan sering kali hanya mengatur tindakan API konfigurasi yang dapat dilakukan pengguna. Setelah kebijakan ini diterapkan, Anda dapat menggunakan kebijakan berbasis sumber daya (atau kontrol akses berbutir halus) di OpenSearch Layanan untuk menawarkan pengguna akses ke indeks dan. OpenSearch APIs

catatan

Pengguna dengan AmazonOpenSearchServiceReadOnlyAccess kebijakan AWS terkelola tidak dapat melihat status kesehatan klaster di konsol. Untuk memungkinkan mereka melihat status kesehatan klaster (dan OpenSearch data lainnya), tambahkan es:ESHttpGet tindakan ke kebijakan akses dan lampirkan ke akun atau peran mereka.

Karena kebijakan berbasis identitas melekat pada pengguna atau peran (utama), JSON tidak menentukan yang utama. Kebijakan berikut memberikan akses ke tindakan yang dimulai dengan Describe dan List. Kombinasi tindakan ini menyediakan akses hanya-baca ke konfigurasi domain, tetapi tidak untuk data yang disimpan dalam domain itu sendiri:


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "es:Describe*",
        "es:List*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Administrator mungkin memiliki akses penuh ke OpenSearch Layanan dan semua data yang disimpan di semua domain:


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "es:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Kebijakan berbasis identitas memungkinkan Anda menggunakan tag untuk mengontrol akses ke API konfigurasi. Kebijakan berikut, misalnya, memungkinkan utama yang terlampir melihat dan memperbarui konfigurasi domain jika domain memiliki tanda team:devops:


{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:UpdateDomainConfig",
      "es:DescribeDomain",
      "es:DescribeDomainConfig"
    ],
    "Effect": "Allow",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/team": [
          "devops"
        ]
      }
    }
  }]
}

Anda juga dapat menggunakan tag untuk mengontrol akses ke OpenSearch API. Kebijakan berbasis tag untuk OpenSearch API hanya berlaku untuk metode HTTP. Misalnya, kebijakan berikut memungkinkan prinsipal terlampir mengirim permintaan GET dan PUT ke OpenSearch API jika domain memiliki tag: environment:production


{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:ESHttpGet",
      "es:ESHttpPut"
    ],
    "Effect": "Allow",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/environment": [
          "production"
        ]
      }
    }
  }]
}

Untuk kontrol OpenSearch API yang lebih terperinci, pertimbangkan untuk menggunakan kontrol akses berbutir halus.

catatan

Setelah menambahkan satu atau beberapa OpenSearch APIs kebijakan berbasis tag, Anda harus melakukan operasi tag tunggal (seperti menambahkan, menghapus, atau memodifikasi tag) agar perubahan diterapkan pada domain. Anda harus menggunakan perangkat lunak layanan R20211203 atau yang lebih baru untuk menyertakan operasi OpenSearch API dalam kebijakan berbasis tag.

OpenSearch Layanan mendukung RequestTag dan kunci kondisi TagKeys global untuk API konfigurasi, bukan OpenSearch API. Kondisi ini hanya berlaku untuk panggilan API yang menyertakan tanda dalam permintaan, seperti CreateDomain, AddTags, dan RemoveTags. Kebijakan berikut memungkinkan prinsipal terlampir membuat domain, tetapi hanya jika kebijakan menyertakan tanda team:it dalam permintaan:


{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "es:CreateDomain",
      "es:AddTags"
    ],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:RequestTag/team": [
          "it"
        ]
      }
    }
  }
}

Untuk rincian lebih lanjut tentang menggunakan tanda untuk kontrol akses dan perbedaan antara kebijakan berbasis sumber daya dan kebijakan berbasis identitas, lihat Panduan Pengguna IAM.

Kebijakan berbasis IP

Kebijakan berbasis IP membatasi akses ke domain ke satu atau lebih alamat IP atau blok CIDR. Secara teknis, kebijakan berbasis IP bukanlah jenis kebijakan yang berbeda. Sebaliknya, mereka hanya kebijakan berbasis sumber daya yang menentukan prinsipal anonim dan menyertakan elemen Ketentuan khusus.

Daya tarik utama kebijakan berbasis IP adalah bahwa mereka mengizinkan permintaan yang tidak ditandatangani ke domain OpenSearch Layanan, yang memungkinkan Anda menggunakan klien seperti curl dan OpenSearch Dasbor atau mengakses domain melalui server proxy. Untuk mempelajari selengkapnya, lihat Menggunakan proxy untuk mengakses OpenSearch Layanan dari Dasbor.

catatan

Jika Anda mengaktifkan akses VPC untuk domain, Anda tidak dapat mengonfigurasi kebijakan berbasis IP. Sebagai gantinya, Anda bisa menggunakan grup keamanan untuk mengontrol alamat IP yang dapat mengakses domain. Untuk informasi selengkapnya, lihat Tentang kebijakan akses pada domain VPC.

Kebijakan berikut memberikan semua permintaan HTTP yang berasal dari akses kisaran IP tertentu ke test-domain:


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.0.2.0/24"
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

Jika domain Anda memiliki titik akhir publik dan tidak menggunakan kontrol akses detail, sebaiknya gabungkan prinsip IAM dan alamat IP. Kebijakan ini memberikan akses HTTP test-user hanya jika permintaan berasal dari kisaran IP yang ditentukan:


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": [
        "arn:aws:iam::987654321098:user/test-user"
      ]
    },
    "Action": [
      "es:ESHttp*"
    ],
    "Condition": {
      "IpAddress": {
        "aws:SourceIp": [
          "192.0.2.0/24"
        ]
      }
    },
    "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
  }]
}

Ketika kebijakan bertabrakan

Kompleksitas muncul ketika kebijakan tidak setuju atau tidak menyebutkan secara eksplisit pengguna. Memahami cara kerja IAM dalam Panduan Pengguna IAM memberikan ringkasan singkat logika evaluasi kebijakan:

Secara default, semua permintaan ditolak.
Izin secara eksplisit akan mengabaikan default ini.
Penolakan secara eksplisit akan mengabaikan izin apa pun.

Misalnya, jika kebijakan berbasis sumber daya memberi Anda akses ke subresource domain ( OpenSearch indeks atau API), tetapi kebijakan berbasis identitas menolak akses Anda, Anda ditolak aksesnya. Jika kebijakan berbasis identitas memberikan akses dan kebijakan berbasis sumber daya tidak menentukan apakah Anda harus memiliki akses atau tidak, Anda diperbolehkan akses. Lihat tabel kebijakan berpotongan berikut untuk ringkasan lengkap hasil untuk subsumber daya domain.

	Diizinkan dalam kebijakan berbasis sumber daya	Ditolak dalam kebijakan berbasis sumber daya	Tidak diperbolehkan atau ditolak dalam kebijakan berbasis sumber daya
Allowed in identity-based policy	Izinkan	Menyangkal	Izinkan
Denied in identity-based policy	Menyangkal	Menyangkal	Menyangkal
Neither allowed nor denied in identity-based policy	Izinkan	Menyangkal	Menyangkal

Referensi elemen kebijakan

OpenSearch Layanan mendukung sebagian besar elemen kebijakan dalam Referensi Elemen Kebijakan IAM, dengan pengecualian. NotPrincipal Tabel berikut menunjukkan elemen yang paling umum.

Elemen kebijakan JSON	Ringkasan
`Version`	Versi bahasa kebijakan saat ini adalah `2012-10-17`. Semua kebijakan akses harus menentukan nilai ini.
`Effect`	Elemen ini menentukan apakah pernyataan memungkinkan atau menolak akses ke tindakan yang ditentukan. Nilai yang benar adalah `Allow` atau `Deny`.
`Principal`	Elemen ini menentukan peran Akun AWS atau IAM atau pengguna yang diizinkan atau ditolak akses ke sumber daya dan dapat mengambil beberapa bentuk: AWS akun: `"Principal":{"AWS": ["123456789012"]}` atau `"Principal":{"AWS": ["arn:aws:iam::123456789012:root"]}` Pengguna IAM: `"Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]}` Peran IAM: `"Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]}` penting Menentukan `*` karakter pengganti akan mengaktifkan akses anonim ke domain, yang tidak kami sarankan kecuali Anda menambahkan kondisi berbasis IP, menggunakan dukungan VPC, atau mengaktifkan kontrol akses detail. Selain itu, periksa dengan cermat kebijakan berikut untuk mengonfirmasi bahwa kebijakan tersebut tidak memberikan akses luas: Kebijakan berbasis identitas yang dilampirkan pada AWS prinsipal terkait (misalnya, peran IAM) Kebijakan berbasis sumber daya yang dilampirkan pada AWS sumber daya terkait (misalnya, kunci KMS) AWS Key Management Service
`Action`	OpenSearch Layanan menggunakan `ESHttp` tindakan untuk metode OpenSearch HTTP. Tindakan lainnya berlaku untuk API konfigurasi. Tindakan `es:` tertentu mendukung izin tingkat sumber daya. Misalnya, Anda dapat memberikan izin pengguna untuk menghapus satu domain tertentu tanpa memberikan izin pengguna untuk menghapus domain mana pun. Tindakan lain hanya berlaku untuk layanan itu sendiri. Misalnya,`es:ListDomainNames` tidak masuk akal dalam konteks domain tunggal dan dengan demikian memerlukan wildcard. Untuk daftar semua tindakan yang tersedia dan apakah itu berlaku untuk subresource domain (`test-domain/`), ke konfigurasi domain (`test-domain`), atau hanya untuk layanan (``), lihat Tindakan, sumber daya, dan kunci kondisi untuk OpenSearch Layanan Amazon di Referensi Otorisasi Layanan* Kebijakan Berbasis sumber daya berbeda dari izin tingkat sumber daya. Kebijakan berbasis sumber daya adalah kebijakan JSON penuh yang melekat pada domain. Izin tingkat sumber daya memungkinkan Anda membatasi tindakan untuk domain atau subsumber daya tertentu. Dalam praktiknya, Anda dapat memikirkan izin tingkat sumber daya sebagai bagian opsional dari sumber daya atau kebijakan berbasis identitas. Meskipun izin tingkat sumber daya untuk `es:CreateDomain` mungkin tampak tidak intuitif—bagaimanapun juga, mengapa memberikan izin kepada pengguna untuk membuat domain yang sudah ada?—penggunaan karakter pengganti memungkinkan Anda menerapkan skema penamaan sederhana untuk domain Anda, seperti `"Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-"`. Tentu saja, tidak ada yang mencegah Anda memasukkan tindakan bersama elemen sumber daya yang kurang ketat, seperti berikut ini: `{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeDomain" ], "Resource": "" } ] }` Untuk mempelajari selengkapnya tentang memasangkan tindakan dan sumber daya, lihat elemen `Resource` dalam tabel ini.
`Condition`	OpenSearch Layanan mendukung sebagian besar kondisi yang dijelaskan dalam kunci konteks kondisi AWS global di Panduan Pengguna IAM. Pengecualian penting termasuk `aws:PrincipalTag` kunci, yang OpenSearch Layanan tidak mendukung. Saat mengonfigurasi kebijakan berbasis IP, Anda menentukan alamat IP atau blok CIDR sebagai kondisi, seperti berikut: `"Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/32" ] } }` Seperti disebutkan dalam Kebijakan berbasis identitas`aws:ResourceTag`, kunci`aws:RequestTag`,, dan `aws:TagKeys` kondisi berlaku untuk API konfigurasi serta OpenSearch APIs.
`Resource`	OpenSearch Layanan menggunakan `Resource` elemen dalam tiga cara dasar: Untuk tindakan yang berlaku untuk OpenSearch Layanan itu sendiri, seperti`es:ListDomainNames`, atau untuk mengizinkan akses penuh, gunakan sintaks berikut: `"Resource": ""` Untuk tindakan yang melibatkan konfigurasi domain, seperti `es:DescribeDomain`, Anda dapat menggunakan sintaks berikut: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name"` Untuk tindakan yang diterapkan ke domain subsumber daya, seperti `es:ESHttpGet`, Anda dapat menggunakan sintaks berikut: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/"` Anda tidak perlu menggunakan wildcard. OpenSearch Layanan memungkinkan Anda menentukan kebijakan akses yang berbeda untuk setiap OpenSearch indeks atau API. Misalnya, Anda dapat membatasi izin pengguna ke indeks `test-index`: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index"` Alih-alih akses penuh ke `test-index`, Anda mungkin lebih memilih untuk membatasi kebijakan hanya pada API pencarian: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/_search"` Anda bahkan dapat mengontrol akses ke dokumen individual: `"Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/test-type/1"` Pada dasarnya, jika OpenSearch mengekspresikan subresource sebagai URI, Anda dapat mengontrol akses ke sana menggunakan kebijakan akses. Untuk kontrol yang lebih besar atas sumber daya yang dapat diakses oleh pengguna, lihat Kontrol akses berbutir halus di Layanan Amazon OpenSearch . Untuk rincian tentang tindakan mana yang mendukung izin tingkat sumber daya, lihat elemen `Action` di tabel ini.

Pilihan lanjutan dan pertimbangan API

OpenSearch Layanan memiliki beberapa opsi lanjutan, salah satunya memiliki implikasi kontrol akses:rest.action.multi.allow_explicit_index. Pada pengaturan default benar, memungkinkan pengguna untuk memotong izin subsumber daya dalam keadaan tertentu.

Misalnya, pertimbangkan kebijakan berbasis sumber daya berikut:


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Resource": [
        "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*",
        "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk"
      ]
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttpGet"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*"
    }
  ]
}

Kebijakan ini memberikan akses test-user penuh ke test-index dan API OpenSearch massal. Hal ini juga memungkinkan permintaan GET untuk restricted-index.

Permintaan pengindeksan berikut, seperti yang Anda harapkan, gagal karena kesalahan izin:


PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1
{
  "title": "Your Name",
  "director": "Makoto Shinkai",
  "year": "2016"
}

Berbeda dengan API indeks, API massal memungkinkan Anda membuat, memperbarui, dan menghapus banyak dokumen dalam satu panggilan. Anda sering menentukan operasi ini di isi permintaan, namun, bukan di URL permintaan. Karena OpenSearch Layanan menggunakan URLs untuk mengontrol akses ke subresource domain, pada kenyataannya, test-user dapat menggunakan API massal untuk membuat perubahan. restricted-index Meskipun pengguna tidak memiliki izin POST pada indeks, permintaan berikut berhasil:


POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk
{ "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } }
{ "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }

Dalam situasi ini, kebijakan akses gagal untuk memenuhi tujuannya. Untuk mencegah pengguna melewati pembatasan semacam ini, Anda dapat mengubah rest.action.multi.allow_explicit_index ke salah. Jika nilai ini salah, semua panggilan ke bulk, mget, dan msearch APIs yang menentukan nama indeks di badan permintaan berhenti bekerja. Dengan kata lain, panggilan ke _bulk tidak lagi bekerja, tapi panggilan ke test-index/_bulk bekerja. Titik akhir kedua ini berisi nama indeks, sehingga Anda tidak perlu menentukan satu di isi permintaan.

OpenSearch Dasbor sangat bergantung pada mget dan msearch, jadi tidak mungkin berfungsi dengan baik setelah perubahan ini. Untuk perbaikan sebagian, Anda dapat meninggalkan rest.action.multi.allow_explicit_index sebagai benar dan menolak akses pengguna tertentu ke satu atau lebih dari ini APIs.

Untuk informasi tentang perubahan pengaturan ini, lihat Pengaturan cluster lanjutan.

Demikian pula, kebijakan berbasis sumber daya berikut berisi dua masalah halus:


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/test-user"
      },
      "Action": "es:ESHttp*",
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    },
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/test-user"
      },
      "Action": "es:ESHttp*",
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*"
    }
  ]
}

Meskipun secara eksplisit menolak, test-user masih dapat melakukan panggilan seperti GET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search dan GET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search untuk mengakses dokumen di restricted-index.
Karena Resource referensi elemen restricted-index/*, test-user tidak memiliki izin untuk langsung mengakses dokumen indeks. Namun, pengguna memiliki izin untuk menghapus seluruh indeks. Untuk mencegah akses dan penghapusan, kebijakan harus menentukan restricted-index*.

Daripada mencampur izin luas dan penolakan terfokus, pendekatan teraman adalah mengikuti prinsip hak istimewa paling rendah dan hanya memberikan izin yang diperlukan untuk melakukan tugas. Untuk informasi selengkapnya tentang mengendalikan akses ke indeks atau OpenSearch operasi individual, lihatKontrol akses berbutir halus di Layanan Amazon OpenSearch .

penting

Menentukan wildcard * memungkinkan akses anonim ke domain Anda. Anda tidak disarankan menggunakan wildcard Selain itu, periksa kebijakan berikut dengan cermat untuk mengonfirmasi bahwa kebijakan tersebut tidak memberikan akses luas:

Kebijakan berbasis identitas yang dilampirkan pada AWS prinsipal terkait (misalnya, peran IAM)
Kebijakan berbasis sumber daya yang dilampirkan pada AWS sumber daya terkait (misalnya, kunci KMS) AWS Key Management Service

Mengonfigurasi kebijakan akses

Untuk petunjuk tentang cara membuat atau memodifikasi kebijakan berbasis sumber daya dan IP di OpenSearch Layanan, lihat. Mengonfigurasi kebijakan akses
Untuk petunjuk cara membuat atau memodifikasi kebijakan berbasis identitas di IAM, lihat Membuat kebijakan IAM di Panduan Pengguna IAM.

Contoh kebijakan tambahan

Meskipun Bab ini mencakup banyak contoh kebijakan, kontrol AWS akses adalah subjek kompleks yang paling baik dipahami melalui contoh. Untuk selengkapnya, lihat Contoh kebijakan berbasis identitas IAM di Panduan Pengguna IAM.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Node-to-node enkripsi

Membuat dan menandatangani Permintaan OpenSearch layanan