Identity and Access Management di Amazon OpenSearch Service - OpenSearch Layanan Amazon
Tipe kebijakanMembuat dan menandatangani Permintaan OpenSearch layananKetika kebijakan bertabrakanReferensi elemen kebijakanOpsi dan API pertimbangan lanjutanMengonfigurasi kebijakan aksesContoh kebijakan tambahan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

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

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

Tipe kebijakan

OpenSearch Layanan mendukung tiga jenis kebijakan akses:

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). Subsumber daya 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 konfigurasi API 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 HTTP GET dan PUT metode untuk semua URIs dalam 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 dalam VPC atau menggunakan kontrol akses berbutir halus, 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 menggunakan () layanan. AWS Identity and Access Management IAM 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. Mereka sering mengatur hanya API tindakan 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 (prinsipal), kebijakan tidak menentukan prinsipal. JSON 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 konfigurasi. API 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 file OpenSearch API. Kebijakan berbasis tag untuk OpenSearch API satu-satunya berlaku untuk HTTP metode. Misalnya, kebijakan berikut memungkinkan prinsipal terlampir mengirim GET dan PUT meminta 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 yang lebih terperinci OpenSearch API, 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 OpenSearch API operasi dalam kebijakan berbasis tag.

OpenSearch Layanan mendukung RequestTag dan kunci kondisi TagKeys global untuk konfigurasiAPI, bukan OpenSearch API. Ketentuan ini hanya berlaku untuk API panggilan yang menyertakan tag dalam permintaan, sepertiCreateDomain,AddTags, danRemoveTags. 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 detail selengkapnya tentang penggunaan tag untuk kontrol akses dan perbedaan antara kebijakan berbasis sumber daya dan berbasis identitas, lihat Panduan Pengguna. IAM

Kebijakan berbasis IP

Kebijakan berbasis IP membatasi akses ke domain ke satu atau beberapa alamat IP atau CIDR blok. 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 OpenSearch Dasbor.

catatan

Jika Anda mengaktifkan VPC akses 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 VPC domain.

Kebijakan berikut memberikan semua HTTP permintaan yang berasal dari akses rentang IP yang ditentukan 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 berbutir halus, sebaiknya gabungkan IAM prinsipal dan alamat IP. Kebijakan ini memberikan test-user HTTP akses hanya jika permintaan berasal dari rentang 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/*"
  }]
}

Membuat dan menandatangani Permintaan OpenSearch layanan

Meskipun Anda mengonfigurasi kebijakan akses berbasis sumber daya yang sepenuhnya terbuka, semua permintaan ke konfigurasi OpenSearch API Layanan harus ditandatangani. Jika kebijakan Anda menentukan IAM peran atau pengguna, permintaan OpenSearch APIs juga harus ditandatangani menggunakan Versi AWS Tanda Tangan 4. Metode penandatanganan berbeda denganAPI:

  • Untuk melakukan panggilan ke konfigurasi OpenSearch LayananAPI, kami sarankan Anda menggunakan salah satu konfigurasi AWS SDKs. SDKsSangat menyederhanakan proses dan dapat menghemat banyak waktu dibandingkan dengan membuat dan menandatangani permintaan Anda sendiri. APITitik akhir konfigurasi menggunakan format berikut:

    es.region.amazonaws.com/2021-01-01/

    Misalnya, permintaan berikut membuat perubahan konfigurasi ke domain movies, tetapi Anda harus menandatanganinya sendiri (tidak disarankan):

    POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/movies/config
{
  "ClusterConfig": {
    "InstanceType": "c5.xlarge.search"
  }
}

    Jika Anda menggunakan salah satuSDKs, seperti Boto 3, SDK secara otomatis menangani penandatanganan permintaan:

    import boto3

client = boto3.client(es)
response = client.update_domain_config(
  DomainName='movies',
  ClusterConfig={
    'InstanceType': 'c5.xlarge.search'
  }
)

    Untuk contoh kode Java, lihat MenggunakanAWSSDK untuk berinteraksi dengan AmazonOpenSearchLayanan.

  • Untuk melakukan panggilan ke OpenSearch APIs, Anda harus menandatangani permintaan Anda sendiri. OpenSearch APIsGunakan format berikut:

    domain-id.region.es.amazonaws.com

    Sebagai contoh, permintaan berikut mencari indeks movies untuk thor:

    GET https://my-domain.us-east-1.es.amazonaws.com/movies/_search?q=thor
catatan

Layanan mengabaikan parameter yang diteruskan URLs untuk HTTP POST permintaan yang ditandatangani dengan Signature Version 4.

Ketika kebijakan bertabrakan

Kompleksitas muncul ketika kebijakan tidak setuju atau tidak menyebutkan secara eksplisit pengguna. Memahami cara IAM kerja dalam Panduan IAM Pengguna 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 subsumber daya domain ( OpenSearch indeks atauAPI), 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 IAMkebijakan dalam Referensi Elemen Kebijakan, dengan pengecualianNotPrincipal. Tabel berikut menunjukkan elemen yang paling umum.

JSONelemen kebijakan 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 Akun AWS atau IAM peran 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"]}

  • IAMpengguna: "Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]}

  • IAMperan: "Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]}

penting

Menentukan * wildcard memungkinkan akses anonim ke domain, yang tidak kami rekomendasikan kecuali Anda menambahkan kondisi berbasis IP, menggunakan VPCdukungan, atau mengaktifkan kontrol akses berbutir halus. 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) AWS Key Management Service KMS
Action

OpenSearch Layanan menggunakan ESHttp* tindakan untuk OpenSearch HTTP metode. Sisa tindakan berlaku untuk konfigurasiAPI.

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 JSON kebijakan lengkap 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 IAM Pengguna. Pengecualian penting termasuk aws:PrincipalTag kunci, yang OpenSearch Layanan tidak mendukung.

Saat mengonfigurasi kebijakan berbasis IP, Anda menentukan alamat IP atau CIDR blokir sebagai kondisi, seperti berikut ini:

"Condition": {
  "IpAddress": {
    "aws:SourceIp": [
      "192.0.2.0/32"
    ]
  }
}

Seperti disebutkan dalam Kebijakan berbasis identitasaws:ResourceTag, tombolaws:RequestTag,, dan aws:TagKeys kondisi berlaku untuk konfigurasi API serta OpenSearch APIs.
Resource

OpenSearch Layanan menggunakan Resource elemen dalam tiga cara dasar:

  • Untuk tindakan yang berlaku untuk OpenSearch Layanan itu sendiri, seperties: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 atauAPI. 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 ketest-index, Anda mungkin lebih memilih untuk membatasi kebijakan hanya untuk pencarianAPI:

    "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 aURI, 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.

Opsi dan API pertimbangan lanjutan

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 OpenSearch sebagian besarAPI. 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 indeksAPI, bulk API memungkinkan Anda membuat, memperbarui, dan menghapus banyak dokumen dalam satu panggilan. Namun, Anda sering menentukan operasi ini di badan permintaan, bukan dalam permintaanURL. Karena OpenSearch Layanan menggunakan URLs untuk mengontrol akses ke subresource domain, pada kenyataannya, test-user dapat menggunakan bulk API 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 iniAPIs.

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) AWS Key Management Service KMS

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 identitasIAM, lihat Membuat IAM kebijakan 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 IAM berbasis identitas di Panduan Pengguna. IAM