# Manajemen izin
Kelola izin guna mengontrol akses untuk identitas orang dan mesin yang memerlukan akses ke AWS dan beban kerja Anda. Izin memungkinkan Anda mengontrol siapa yang dapat mengakses hal tertentu, beserta kondisinya. Dengan menetapkan izin ke identitas manusia dan mesin tertentu, Anda memberinya akses ke tindakan layanan tertentu di sumber daya tertentu. Selain itu, Anda menentukan kondisi yang harus dipenuhi agar akses dapat diberikan.
Terdapat beberapa cara untuk memberikan akses ke beberapa jenis sumber daya yang berbeda. Salah satunya adalah menggunakan beberapa jenis kebijakan yang berbeda.
[Kebijakan berbasis identitas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) di IAM *dikelola* atau *inline*, dan dilampirkan ke identitas IAM, termasuk pengguna, grup, atau peran. Kebijakan ini memungkinkan Anda menentukan apa yang dapat dilakukan oleh identitas (izinnya). Kebijakan berbasis identitas dapat dikategorikan lebih lanjut.
**Kebijakan terkelola** – Kebijakan berbasis identitas mandiri yang dapat diterapkan ke beberapa pengguna, grup, dan peran dalam akun AWS Anda. Ada dua jenis kebijakan terkelola:
+ **Kebijakan yang dikelola AWS** – Kebijakan terkelola yang dibuat dan dikelola oleh AWS.
+ **Kebijakan yang dikelola pelanggan** – Kebijakan terkelola yang Anda buat dan kelola dalam akun AWS Anda. Kebijakan yang dikelola pelanggan memberikan kontrol yang lebih presisi terhadap kebijakan Anda dibandingkan dengan kebijakan yang dikelola AWS.
Kebijakan terkelola adalah metode yang diutamakan untuk menerapkan izin. Namun, Anda juga dapat menggunakan kebijakan sebaris yang Anda tambahkan langsung ke pengguna, grup, atau peran tunggal. Kebijakan inline mempertahankan hubungan satu-ke-satu yang ketat antara kebijakan dan sebuah identitas. Kebijakan sebaris akan dihapus saat Anda menghapus identitas.
Di sebagian besar kasus, Anda harus membuat sendiri kebijakan yang dikelola pelanggan dengan mengikuti prinsip [hak akses paling rendah](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege).
[Kebijakan berbasis sumber daya](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dilampirkan pada sumber daya. Sebagai contoh, kebijakan bucket S3 merupakan kebijakan berbasis sumber daya. Kebijakan ini memberikan izin kepada principal yang dapat berada di akun yang sama atau berbeda dengan sumber daya. Untuk daftar layanan yang mendukung kebijakan berbasis sumber daya, silakan lihat [layanan-layanan AWS yang bisa digunakan dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
[Batasan izin](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) menggunakan kebijakan terkelola untuk menetapkan izin maksimum yang dapat ditetapkan administrator. Dengan demikian, Anda dapat mendelegasikan kemampuan untuk membuat dan mengelola izin kepada developer, seperti pembuatan peran IAM, tetapi membatasi izin yang dapat mereka berikan agar mereka tidak dapat memperluas izin mereka menggunakan izin yang telah mereka buat.
[Kontrol akses berbasis atribut (ABAC):](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) di AWS memungkinkan Anda memberikan izin berdasarkan atribut yang disebut tanda. Tanda dapat dilampirkan pada principal IAM (pengguna atau peran) dan pada sumber daya AWS. Administrator dapat membuat kebijakan IAM yang dapat digunakan kembali yang menerapkan izin berdasarkan atribut principal IAM. Sebagai contoh, sebagai administrator, Anda dapat menggunakan kebijakan IAM tunggal untuk memberi developer di organisasi Anda akses ke sumber daya AWS yang cocok dengan tanda proyek mereka. Seiring tim developer menambahkan sumber daya ke proyek, izin diterapkan secara otomatis berdasarkan atribut, sehingga tidak memerlukan pembaruan kebijakan untuk setiap sumber daya baru.
[Kebijakan Kontrol Layanan (SCP) organisasi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_scp) menentukan izin maksimum untuk anggota akun organisasi atau unit organisasional (OU). SCP *membatasi* izin yang diberikan oleh kebijakan berbasis identitas atau kebijakan berbasis sumber daya kepada entitas (pengguna atau peran) dalam akun, tetapi *tidak memberikan* izin.
[Kebijakan sesi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) mengambil peran atau pengguna gabungan. Lewati kebijakan sesi saat menggunakan kebijakan Sesi CLI AWS atau API AWS untuk membatasi izin yang diberikan oleh kebijakan berbasis identitas peran atau pengguna ke sesi tersebut. Kebijakan ini *membatasi* izin untuk sesi yang dibuat, tetapi *tidak memberikan* izin. Untuk informasi selengkapnya, lihat [Kebijakan Sesi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session).
**Topics**
+ [SEC03-BP01 Menetapkan persyaratan akses](sec_permissions_define.md)
+ [SEC03-BP02 Memberikan hak akses paling rendah](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Menerapkan proses akses darurat](sec_permissions_emergency_process.md)
+ [SEC03-BP04 Mengurangi izin secara terus-menerus](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 Tentukan pagar pembatas izin untuk organisasi Anda](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 Mengelola akses berdasarkan siklus hidup](sec_permissions_lifecycle.md)
+ [SEC03-BP07 Menganalisis akses publik dan lintas akun](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 Membagikan sumber daya secara aman dalam organisasi Anda](sec_permissions_share_securely.md)
+ [SEC03-BP09 Membagikan sumber daya secara aman kepada pihak ketiga](sec_permissions_share_securely_third_party.md)
# SEC03-BP01 Menetapkan persyaratan akses
Tiap-tiap komponen atau sumber daya beban kerja Anda perlu diakses oleh administrator, pengguna akhir, atau komponen-komponen lainnya. Penetapan harus jelas tentang siapa atau apa yang harus memiliki akses ke tiap-tiap komponen, pilih tipe identitas dan metode autentikasi serta otorisasi yang sesuai.
**Anti-pola umum:**
+ Melakukan hard-coding atau menyimpan rahasia di dalam aplikasi Anda.
+ Memberikan izin kustom untuk masing-masing pengguna.
+ Menggunakan kredensial yang sudah berumur panjang.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Tiap-tiap komponen atau sumber daya beban kerja Anda perlu diakses oleh administrator, pengguna akhir, atau komponen-komponen lainnya. Penetapan harus jelas tentang siapa atau apa yang harus memiliki akses ke tiap-tiap komponen, pilih tipe identitas dan metode autentikasi serta otorisasi yang sesuai.
Akses rutin ke Akun AWS dalam organisasi harus disediakan dengan menggunakan [akses federasi](https://aws.amazon.com/identity/federation/) atau penyedia identitas tersentralisasi. Anda juga sebaiknya melakukan sentralisasi manajemen identitas Anda dan memastikan terdapat praktik yang mapan yang digunakan untuk mengintegrasikan akses AWS ke siklus hidup akses karyawan Anda. Misalnya, saat ada seorang karyawan yang berganti peran pekerjaan dengan level akses berbeda, maka keanggotaan grupnya juga harus berubah agar sesuai dengan persyaratan akses baru yang berlaku padanya.
Saat Anda menetapkan persyaratan akses untuk identitas selain manusia, Anda harus menentukan aplikasi dan komponen mana yang memerlukan akses dan bagaimana izin diberikan. Menggunakan peran IAM yang dibangun dengan model akses hak akses paling rendah adalah pendekatan yang disarankan. [AWS Kebijakan terkelola](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) menyediakan kebijakan IAM yang telah ditetapkan sebelumnya yang mencakup kasus-kasus penggunaan paling umum.
Layanan-layanan AWS, seperti [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) dan [Penyimpanan Parameter AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html), dapat membantu Anda memisahkan rahasia dari aplikasi atau beban kerja dengan aman. Di Secrets Manager, Anda dapat membuat rotasi otomatis untuk kredensial Anda. Anda dapat menggunakan Systems Manager untuk merujuk parameter di skrip, perintah, dokumen SSM, konfigurasi, dan alur kerja otomatisasi Anda menggunakan nama unik yang telah Anda tentukan saat membuat parameter tersebut.
Anda dapat menggunakan [AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) untuk mendapatkan [kredensial keamanan sementara di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) untuk beban kerja yang berjalan di luar AWS. Beban kerja Anda dapat menggunakan [kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dan [peran IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) yang sama yang Anda gunakan dengan aplikasi AWS untuk mengakses sumber daya AWS.
Jika memungkinkan, Anda sebaiknya menggunakan kredensial sementara jangka pendek, bukan kredensial statis jangka panjang. Untuk skenario di mana Anda memerlukan pengguna dengan akses yang terprogram dan kredensial jangka panjang, gunakan [informasi kunci akses yang terakhir digunakan](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) untuk merotasi dan menghapus kunci akses.
Pengguna membutuhkan akses terprogram jika ingin berinteraksi dengan AWS di luar Konsol Manajemen AWS. Cara memberikan akses programatis bergantung pada jenis pengguna yang mengakses AWS.
Untuk memberi pengguna akses programatis, pilih salah satu opsi berikut.
****
| Pengguna mana yang membutuhkan akses programatis? | Untuk | Oleh |
| --- | --- | --- |
| IAM | (Direkomendasikan) Gunakan kredensial konsol sebagai kredensial sementara untuk menandatangani permintaan programatis ke AWS CLI, SDK AWS, atau API AWS. | Mengikuti petunjuk untuk antarmuka yang ingin Anda gunakan. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
| Identitas tenaga kerja (Pengguna yang dikelola di Pusat Identitas IAM) | Gunakan kredensial sementara untuk menandatangani permintaan programatis ke AWS CLI, SDK AWS, atau API AWS. | Mengikuti petunjuk untuk antarmuka yang ingin Anda gunakan. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
| IAM | Gunakan kredensial sementara untuk menandatangani permintaan programatis ke AWS CLI, SDK AWS, atau API AWS. | Ikuti petunjuk dalam [Menggunakan kredensial sementara dengan sumber daya AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) dalam Panduan Pengguna IAM. |
| IAM | (Tidak direkomendasikan)Gunakan kredensial jangka panjang untuk menandatangani permintaan programatis ke AWS CLI, AWS SDK, atau API AWS. | Mengikuti petunjuk untuk antarmuka yang ingin Anda gunakan. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
## Sumber daya
**Dokumen terkait:**
+ [Kontrol akses berbasis atribut (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
+ [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
+ [AWS Kebijakan terkelola untuk Pusat Identitas IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [AWS Ketentuan kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)
+ [Kasus penggunaan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html)
+ [Hapus kredensial yang tidak perlu](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [Bekerja dengan Kebijakan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [Cara mengontrol akses ke sumber daya AWS berdasarkan Akun AWS, OU, atau organisasi](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [Identifikasi, atur, dan kelola rahasia secara mudah dengan menggunakan pencarian yang ditingkatkan di AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**Video terkait:**
+ [Menjadi Master Kebijakan IAM dalam 60 Menit atau Kurang](https://youtu.be/YQsK4MtsELU)
+ [Pemisahan Tugas, Hak Akses Paling Rendah, Delegasi, dan CI/CD](https://youtu.be/3H0i7VyTu70)
+ [Merampingkan manajemen identitas dan akses untuk inovasi](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 Memberikan hak akses paling rendah
Berikan hanya akses yang diperlukan pengguna untuk melakukan tindakan tertentu pada sumber daya tertentu dalam kondisi tertentu. Gunakan atribut grup dan identitas untuk menetapkan izin secara dinamis dalam skala besar, bukannya menentukan izin satu per satu untuk setiap pengguna. Misalnya, Anda dapat memberi sebuah grup developer akses dalam mengelola sumber daya untuk proyek mereka saja. Dengan cara ini, jika seorang developer keluar dari proyek, maka aksesnya secara otomatis dicabut tanpa mengubah kebijakan akses dasar.
**Hasil yang diinginkan:** Pengguna hanya memiliki izin minimum yang diperlukan untuk fungsi pekerjaan spesifik mereka. Anda menggunakan Akun AWS terpisah untuk mengisolasi developer dari lingkungan produksi. Ketika developer perlu mengakses lingkungan produksi untuk tugas-tugas tertentu, mereka diberi akses terbatas dan terkontrol hanya selama durasi tugas tersebut. Akses produksi mereka segera dicabut setelah mereka menyelesaikan pekerjaan yang diperlukan. Anda melakukan peninjauan reguler atas izin dan segera mencabutnya saat tidak diperlukan lagi, seperti saat pengguna berganti peran atau meninggalkan organisasi. Anda membatasi hak administrator ke grup kecil yang tepercaya untuk mengurangi paparan risiko. Anda memberi akun mesin atau sistem hanya izin minimum yang diperlukan untuk melakukan tugas yang dimaksudkan.
**Anti-pola umum:**
+ Secara default, Anda memberikan izin administrator kepada pengguna.
+ Anda menggunakan akun pengguna root untuk aktivitas sehari-hari.
+ Anda membuat kebijakan yang terlalu permisif tanpa cakupan yang tepat.
+ Peninjauan izin Anda jarang dilakukan, sehingga menyebabkan penyimpangan izin.
+ Anda hanya mengandalkan kontrol akses berbasis atribut untuk isolasi lingkungan atau manajemen izin.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Tinggi
## Panduan implementasi
Prinsip [hak akses paling rendah](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) menyatakan bahwa identitas hanya boleh mendapatkan izin untuk melakukan serangkaian tindakan terkecil yang diperlukan untuk memenuhi tugas tertentu. Hal ini akan menyeimbangkan kegunaan, efisiensi, dan keamanan. Pengoperasian berdasarkan prinsip ini akan membantu Anda membatasi akses yang tidak diinginkan dan membantu Anda dalam memantau siapa saja yang memiliki akses ke sumber daya yang mana. Pengguna IAM dan peran IAM tidak memiliki izin secara default. Pengguna root memiliki akses penuh secara default dan harus dikontrol, dipantau, dan digunakan secara ketat hanya untuk [tugas-tugas yang memerlukan akses root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html).
Kebijakan IAM digunakan untuk memberikan izin secara eksplisit ke peran IAM atau sumber daya tertentu. Contohnya, kebijakan berbasis identitas dapat dilampirkan ke grup IAM, sedangkan bucket S3 dapat dikontrol oleh kebijakan berbasis sumber daya.
Saat Anda membuat kebijakan IAM, Anda dapat menentukan tindakan layanan, sumber daya, dan kondisi yang harus terpenuhi agar AWS dapat memberikan atau menolak akses. AWS mendukung beragam kondisi untuk membantu Anda menyaring akses. Misalnya, dengan menggunakan [kunci kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgID, Anda dapat menolak tindakan jika pemohon bukan bagian dari Organisasi AWS Anda.
Anda juga dapat mengontrol permintaan yang dibuat oleh layanan AWS atas nama Anda, seperti AWS CloudFormation yang membuat fungsi AWS Lambda, dengan menggunakan kunci kondisi CalledVia. Anda dapat menggunakan berbagai macam kebijakan secara berlapis untuk membuat sistem pertahanan yang mendalam dan membatasi izin keseluruhan untuk pengguna Anda. Anda juga bisa membatasi izin yang dapat diberikan beserta kondisinya. Misalnya, Anda dapat mengizinkan tim beban kerja Anda membuat kebijakan IAM mereka sendiri untuk sistem yang mereka bangun, tetapi hanya jika mereka menerapkan [Batasan Izin](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) untuk membatasi izin maksimum yang dapat mereka berikan.
### Langkah-langkah implementasi
+ **Implementasikan kebijakan hak akses paling rendah**: Tetapkan kebijakan akses dengan hak akses paling rendah ke grup dan peran IAM untuk mencerminkan peran atau fungsi pengguna yang telah Anda tetapkan.
+ **Isolasikan lingkungan pengembangan dan produksi melalui Akun AWS terpisah**: Gunakan Akun AWS terpisah untuk lingkungan pengembangan dan produksi, serta kontrol akses di antara keduanya menggunakan [kebijakan kontrol layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), kebijakan sumber daya, dan kebijakan identitas.
+ **Kebijakan dasar penggunaan API**: Salah satu cara untuk menentukan izin yang diperlukan adalah dengan melakukan peninjauan terhadap log AWS CloudTrail. Anda dapat menggunakan peninjauan ini untuk membuat izin yang disesuaikan dengan tindakan yang benar-benar dilakukan oleh pengguna di dalam AWS. [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) dapat [secara otomatis menghasilkan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) sebuah kebijakan IAM berdasarkan aktivitas akses. Anda dapat menggunakan IAM Access Advisor di tingkat organisasi atau akun untuk [melacak informasi yang terakhir diakses untuk kebijakan tertentu](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html).
+ **Pertimbangkan untuk menggunakan [kebijakan terkelola AWS untuk fungsi pekerjaan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)**: Saat Anda mulai membuat kebijakan izin yang terperinci, sebaiknya gunakan kebijakan terkelola AWS untuk peran pekerjaan umum, seperti penagihan, administrator basis data, dan ilmuwan data. Kebijakan ini dapat membantu Anda mempersempit akses yang dimiliki pengguna sambil menentukan cara menerapkan kebijakan hak akses paling rendah.
+ **Hapus izin yang tidak perlu:** Deteksi dan hapus entitas, kredensial, dan izin IAM yang tidak digunakan untuk mewujudkan prinsip hak akses paling rendah. Anda dapat menggunakan [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) untuk mengidentifikasi akses eksternal dan tidak terpakai, serta [pembuatan kebijakan IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) dapat membantu menyempurnakan kebijakan izin.
+ **Pastikan bahwa para pengguna memiliki akses terbatas ke lingkungan produksi:** Pengguna hanya boleh memiliki akses ke lingkungan produksi jika memiliki kasus penggunaan yang valid. Setelah pengguna menyelesaikan tugas-tugas tertentu yang memerlukan akses produksi, akses harus dicabut. Pembatasan akses ke lingkungan produksi akan membantu Anda mencegah kejadian tak terduga yang memengaruhi produksi dan memperkecil cakupan dampak akses yang tidak diharapkan.
+ **Pertimbangkan batasan izin:** [Batasan izin](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) adalah sebuah fitur untuk menggunakan sebuah kebijakan terkelola yang mengatur izin maksimum yang dapat diberikan oleh kebijakan berbasis identitas ke sebuah entitas IAM. Batasan izin entitas mengizinkannya untuk melakukan hanya tindakan yang diizinkan oleh kebijakan berbasis identitas dan batasan izinnya.
+ **Efektifkan akses menggunakan kontrol akses berbasis atribut dan tanda sumber daya**: [Kontrol akses berbasis atribut (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) yang menggunakan tanda sumber daya dapat digunakan untuk mengefektifkan izin jika didukung. Anda dapat menggunakan model ABAC yang membandingkan tanda principal dengan tanda sumber daya untuk mengefektifkan akses berdasarkan dimensi kustom yang Anda tentukan. Pendekatan ini dapat menyederhanakan dan mengurangi jumlah kebijakan izin di organisasi Anda.
+ Sebaiknya ABAC hanya digunakan untuk kontrol akses ketika principal dan sumber daya dimiliki oleh Organisasi AWS Anda. Pihak eksternal dapat menggunakan nama dan nilai tanda yang sama dengan organisasi Anda untuk principal dan sumber daya mereka sendiri. Jika Anda hanya mengandalkan pasangan nama-nilai ini untuk memberikan akses ke principal atau sumber daya pihak eksternal, Anda mungkin akan memberikan izin yang tidak dimaksudkan.
+ **Gunakan kebijakan kontrol layanan untuk AWS Organizations:** [Kebijakan kontrol layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) secara terpusat mengontrol izin maksimum yang tersedia bagi akun anggota yang ada di organisasi Anda. Yang terpenting, Anda dapat menggunakan kebijakan kontrol layanan untuk membatasi izin pengguna root di dalam akun anggota. Pertimbangkan juga untuk menggunakan AWS Control Tower, yang akan menyediakan kontrol terkelola preskriptif yang akan makin memperkaya AWS Organizations. Anda juga dapat menentukan kontrol Anda sendiri di dalam Control Tower.
+ **Menetapkan sebuah kebijakan siklus hidup pengguna untuk organisasi Anda:** Kebijakan siklus hidup pengguna akan menentukan tugas yang akan dilakukan saat pengguna berada di AWS, mengubah peran atau cakupan pekerjaan, atau tidak lagi memerlukan akses ke AWS. Lakukan peninjauan izin pada setiap langkah dalam siklus hidup pengguna untuk memverifikasi bahwa izin dibatasi dengan sesuai dan untuk menghindari penyimpangan izin.
+ **Tetapkan jadwal reguler untuk meninjau izin dan menghapus izin yang tidak diperlukan:** Anda harus secara teratur melakukan peninjauan akses pengguna untuk memverifikasi bahwa pengguna tidak memiliki akses yang terlalu permisif. [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) dan IAM Access Analyzer dapat membantu Anda selama audit izin pengguna.
+ **Tetapkan matriks peran pekerjaan:** Matriks peran pekerjaan memberikan visualisasi dari berbagai peran dan tingkat akses yang diperlukan dalam jejak AWS Anda. Dengan sebuah matriks peran kerja, Anda dapat menentukan dan memisahkan izin berdasarkan tanggung jawab pengguna di dalam organisasi. Gunakan grup alih-alih menerapkan izin langsung ke masing-masing pengguna atau peran.
## Sumber daya
**Dokumen terkait:**
+ [Berikan hak akses paling rendah](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Batasan izin untuk entitas IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [Teknik untuk menulis kebijakan IAM dengan hak akses paling rendah](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer akan mempermudah Anda dalam mengimplementasikan izin dengan hak akses paling rendah dengan membuat kebijakan IAM berdasarkan aktivitas akses](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [Delegasikan manajemen izin kepada developer dengan menggunakan batasan izin IAM](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)
+ [Menyempurnakan Izin dengan menggunakan informasi yang terakhir kali diakses](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [Tipe kebijakan IAM dan kapan harus digunakan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [Menguji kebijakan IAM dengan simulator kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [Pagar Pembatas di AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [Arsitektur Zero Trust: Sebuah perspektif AWS](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [Cara mengimplementasikan prinsip hak akses paling rendah dengan CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
+ [Kontrol akses berbasis atribut (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [Mengurangi cakupan kebijakan dengan melihat aktivitas pengguna](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [Lihat akses peran](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)
+ [Gunakan Penandaan untuk Mengatur Lingkungan Anda dan Mendorong Akuntabilitas](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html)
+ [Strategi Penandaan AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ [Penandaan pada sumber daya AWS](https://aws.amazon.com/premiumsupport/knowledge-center/tagging-resources/)
**Video terkait:**
+ [Manajemen izin generasi berikutnya](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [Zero Trust: Sebuah perspektif AWS](https://www.youtube.com/watch?v=1p5G1-4s1r0)
# SEC03-BP03 Menerapkan proses akses darurat
Buat proses yang memungkinkan akses darurat ke beban kerja Anda jika terjadi masalah pada penyedia identitas tersentralisasi Anda.
Anda harus merancang desain proses untuk berbagai mode kegagalan yang dapat mengakibatkan terjadinya sebuah peristiwa darurat. Misalnya, dalam keadaan normal, pengguna tenaga kerja Anda melakukan federasi ke cloud menggunakan penyedia identitas tersentralisasi ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) untuk mengelola beban kerja mereka. Namun, jika penyedia identitas tersentralisasi Anda gagal, atau konfigurasi untuk federasi di cloud diubah, maka pengguna tenaga kerja Anda mungkin tidak dapat melakukan federasi ke cloud. Proses akses darurat akan memungkinkan administrator yang berwenang untuk mengakses sumber daya cloud Anda melalui cara alternatif (seperti bentuk federasi alternatif atau akses pengguna langsung) untuk memperbaiki masalah dengan konfigurasi federasi atau beban kerja Anda. Proses akses darurat tersebut digunakan sampai mekanisme federasi normal berhasil dipulihkan.
**Hasil yang diinginkan:**
+ Anda telah menentukan dan mendokumentasikan mode kegagalan yang terhitung sebagai sebuah keadaan darurat: pertimbangkan keadaan normal Anda dan sistem yang diandalkan oleh para pengguna untuk mengelola beban kerja mereka. Pertimbangkan bagaimana masing-masing dependensi ini dapat gagal dan menyebabkan terjadinya sebuah keadaan darurat. Anda mungkin akan menemukan pertanyaan dan praktik-praktik terbaik dalam [Pilar Keandalan](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html) yang berguna untuk mengidentifikasi mode kegagalan dan merancang arsitektur sistem yang lebih tangguh untuk meminimalkan kemungkinan terjadinya kegagalan.
+ Anda telah mendokumentasikan langkah-langkah yang harus diikuti untuk mengonfirmasi bahwa kegagalan dianggap sebagai keadaan darurat. Misalnya, Anda dapat meminta administrator identitas Anda untuk memeriksa status penyedia identitas utama dan siaga Anda dan, jika keduanya tidak tersedia, maka Anda harus mengumumkan peristiwa darurat untuk kegagalan penyedia identitas.
+ Anda telah menentukan sebuah proses akses darurat khusus untuk masing-masing jenis mode darurat atau kegagalan. Pengkhususan ini dapat mengurangi godaan di pihak pengguna Anda untuk terlalu sering menggunakan sebuah proses umum untuk semua jenis keadaan darurat. Proses akses darurat Anda menggambarkan keadaan di mana masing-masing proses harus digunakan dan, sebaliknya, situasi di mana proses tidak boleh digunakan dan menunjuk ke proses alternatif yang mungkin berlaku.
+ Proses Anda didokumentasikan dengan baik dengan instruksi yang mendetail dan playbook yang dapat diikuti dengan cepat dan dengan efisien. Ingatlah bahwa sebuah peristiwa darurat dapat menjadi saat-saat yang memusingkan bagi para pengguna Anda dan mereka sedang berada di bawah tekanan waktu yang ekstrem, jadi buatlah desain proses yang sesederhana mungkin.
**Anti-pola umum:**
+ Anda tidak memiliki proses akses darurat yang didokumentasikan dengan baik dan teruji dengan baik. Pengguna Anda tidak siap untuk menghadapi sebuah keadaan darurat dan mengikuti proses yang diimprovisasi ketika ada sebuah peristiwa darurat yang muncul.
+ Proses akses darurat Anda bergantung pada sistem yang sama (seperti penyedia identitas tersentralisasi) dengan mekanisme akses normal Anda. Ini artinya, kegagalan sistem tersebut dapat memengaruhi mekanisme akses normal dan darurat Anda dan akan mengganggu kemampuan Anda untuk pulih dari kegagalan tersebut.
+ Proses akses darurat Anda digunakan dalam situasi yang tidak darurat. Misalnya, pengguna Anda sering kali menyalahgunakan proses akses darurat karena mereka merasa lebih mudah melakukan perubahan secara langsung daripada mengirimkan perubahan melalui sebuah pipeline.
+ Proses akses darurat Anda tidak menghasilkan log yang memadai untuk mengaudit proses tersebut, atau log tersebut tidak dipantau untuk mendapatkan peringatan mengenai adanya potensi penyalahgunaan proses.
**Manfaat menjalankan praktik terbaik ini:**
+ Dengan memiliki proses akses darurat yang didokumentasikan dengan baik dan teruji dengan baik, Anda dapat mengurangi waktu yang dibutuhkan pengguna untuk merespons dan menyelesaikan sebuah peristiwa darurat. Hal ini dapat menghasilkan lebih sedikit waktu henti dan ketersediaan yang lebih tinggi untuk layanan-layanan yang Anda berikan kepada pelanggan Anda.
+ Anda dapat melacak setiap permintaan akses darurat dan mendeteksi serta memberikan peringatan mengenai adanya upaya penyalahgunaan proses untuk peristiwa yang tidak darurat.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan**: Sedang
## Panduan implementasi
Bagian ini akan memberikan Anda panduan untuk membuat proses akses darurat untuk beberapa mode kegagalan yang berkaitan dengan beban kerja yang di-deploy di AWS, dimulai dengan panduan umum yang berlaku untuk semua mode kegagalan dan dilanjutkan dengan panduan khusus berdasarkan jenis mode kegagalan yang berlaku.
**Panduan umum untuk semua mode kegagalan**
Pertimbangkan hal berikut saat Anda membuat desain proses akses darurat untuk sebuah mode kegagalan:
+ Dokumentasikan kondisi awal (pre-conditions) dan asumsi mengenai proses tersebut: kapan proses tersebut harus digunakan dan kapan proses tersebut tidak boleh digunakan. Penting untuk memiliki detail mode kegagalan dan mendokumentasikan asumsi, seperti status keadaan sistem-sistem terkait lainnya. Misalnya, proses untuk Mode Kegagalan 2 mengasumsikan bahwa penyedia identitas tersedia, tetapi konfigurasi yang ditetapkan di AWS sudah dimodifikasi atau telah kedaluwarsa.
+ Sejak awal, buat sumber daya yang dibutuhkan oleh proses akses darurat ([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html)). Misalnya, buat akses Akun AWS darurat di awal dengan pengguna IAM dan peran IAM, dan peran IAM lintas akun di semua akun beban kerja. Hal ini akan memastikan bahwa semua sumber daya ini siap dan tersedia ketika ada sebuah peristiwa darurat yang terjadi. Dengan membuat sumber daya sebelumnya, artinya Anda tidak memiliki dependensi pada API [bidang kontrol](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) AWS (digunakan untuk membuat dan memodifikasi sumber daya AWS) yang mungkin tidak akan tersedia ketika ada keadaan darurat yang terjadi. Selanjutnya, dengan membuat sumber daya IAM sebelumnya, artinya Anda tidak perlu memperhitungkan [potensi penundaan yang disebabkan terjadinya konsistensi di akhir](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency).
+ Sertakan proses-proses akses darurat sebagai bagian dari rencana manajemen insiden Anda ([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)). Dokumentasikan bagaimana peristiwa darurat dilacak dan dikomunikasikan kepada orang lain yang ada dalam organisasi Anda, seperti tim sejawat, pimpinan Anda, dan, jika ada, secara eksternal kepada para pelanggan dan partner bisnis Anda.
+ Tentukan proses permintaan akses darurat yang ada dalam sistem alur kerja permintaan layanan yang ada, jika Anda memilikinya. Biasanya, sistem alur kerja semacam ini akan memungkinkan Anda untuk membuat formulir penerimaan informasi untuk mengumpulkan informasi tentang permintaan, melacak permintaan melalui setiap tahap alur kerja, dan menambahkan langkah-langkah persetujuan otomatis dan manual. Hubungkan setiap permintaan dengan sebuah peristiwa darurat terkait yang dilacak dalam sistem manajemen insiden Anda. Dengan memiliki sistem yang seragam untuk akses darurat, Anda dapat melacak permintaan tersebut dalam satu sistem tunggal, menganalisis tren penggunaan, dan meningkatkan kualitas proses Anda.
+ Pastikan bahwa proses akses darurat Anda hanya dapat dimulai oleh pengguna yang berwenang dan itu memerlukan persetujuan dari rekan sejawat atau manajemen pengguna yang sesuai. Proses persetujuan harus beroperasi secara efektif baik di dalam maupun di luar jam kerja. Tentukan bagaimana permintaan persetujuan mengizinkan pemberi persetujuan sekunder jika pemberi persetujuan utama tidak tersedia dan bagaimana permintaan itu dieskalasikan ke rantai manajemen Anda hingga mendapatkan persetujuan.
+ Terapkan mekanisme pencatatan log, pemantauan, dan peringatan yang efektif untuk proses dan mekanisme akses darurat. Buat log audit yang mendetail untuk semua upaya yang berhasil dan upaya yang gagal dalam mendapatkan akses darurat. Korelasikan aktivitas dengan peristiwa darurat yang sedang berlangsung dari sistem manajemen insiden Anda, dan jalankan peringatan jika tindakan terjadi di luar periode waktu yang diharapkan atau jika akun akses darurat digunakan selama operasi normal. Akun akses darurat hanya boleh diakses selama keadaan darurat karena prosedur break-glass dapat dianggap sebagai backdoor. Integrasikan dengan alat informasi keamanan dan manajemen peristiwa (SIEM) Anda atau [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) untuk melaporkan dan mengaudit semua aktivitas selama periode akses darurat. Setelah kembali ke operasi normal, rotasikan kredensial akses darurat secara otomatis, dan beri tahu tim yang relevan.
+ Lakukan pengujian terhadap proses akses darurat secara berkala untuk memverifikasi bahwa langkah-langkahnya sudah jelas dan memberikan tingkat akses yang benar dengan cepat dan efisien. Proses akses darurat Anda harus diuji sebagai bagian dari simulasi respons insiden ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) dan tes pemulihan bencana ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)).
**Mode Kegagalan 1: Penyedia identitas yang digunakan untuk melakukan federasi ke AWS tidak tersedia**
Sebagaimana dijelaskan di [SEC02-BP04 Mengandalkan penyedia identitas tersentralisasi](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), kami sarankan Anda mengandalkan penyedia identitas tersentralisasi untuk melakukan federasi pengguna tenaga kerja Anda untuk memberikan akses ke Akun AWS. Anda dapat melakukan federasi ke beberapa Akun AWS yang ada di organisasi AWS Anda dengan menggunakan Pusat Identitas IAM, atau Anda dapat melakukan federasi ke Akun AWS secara terpisah dengan menggunakan IAM. Dalam kedua kasus tersebut, pengguna tenaga kerja melakukan autentikasi dengan penyedia identitas tersentralisasi Anda sebelum diarahkan ke titik akhir masuk AWS ke masuk tunggal.
Apabila penyedia identitas tersentralisasi Anda tidak tersedia, pengguna tenaga kerja Anda tidak dapat melakukan federasi ke Akun AWS atau mengelola beban kerja mereka. Dalam peristiwa darurat ini, Anda dapat menyediakan proses akses darurat untuk sekelompok kecil administrator untuk mengakses Akun AWS untuk melakukan tugas-tugas penting yang tidak dapat ditunda sampai penyedia identitas tersentralisasi Anda kembali aktif. Misalnya, penyedia identitas Anda tidak tersedia selama 4 jam dan selama periode tersebut Anda perlu mengubah batas atas grup Amazon EC2 Auto Scaling di sebuah akun Produksi untuk menangani terjadinya lonjakan lalu lintas pelanggan yang tidak terduga. Administrator darurat Anda harus mengikuti proses akses darurat untuk mendapatkan akses ke Akun AWS khusus produksi dan melakukan perubahan-perubahan yang diperlukan.
Proses akses darurat tersebut bergantung pada Akun AWS akses darurat yang telah dibuat sebelumnya yang digunakan semata-mata untuk akses darurat dan memiliki sumber daya AWS (seperti peran IAM dan pengguna IAM) yang digunakan untuk mendukung proses akses darurat tersebut. Selama operasi normal, tidak ada yang boleh mengakses akun akses darurat tersebut dan Anda harus melakukan pemantauan atas dan memberikan peringatan mengenai terjadinya penyalahgunaan akun ini (untuk lebih jelasnya, lihat bagian panduan umum sebelumnya).
Akun akses darurat memiliki peran IAM akses darurat dengan izin untuk mengambil peran lintas akun yang ada di Akun AWS yang memerlukan akses darurat. Peran IAM ini telah dibuat sebelumnya dan dikonfigurasi dengan kebijakan-kebijakan kepercayaan yang mempercayai peran IAM yang dimiliki akun darurat tersebut.
Proses akses darurat dapat menggunakan salah satu pendekatan berikut ini:
+ Anda dapat membuat satu set [pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) untuk administrator darurat Anda yang ada di akun akses darurat dengan kata sandi yang kuat dan token MFA yang sudah dikaitkan. Set pengguna IAM ini memiliki izin untuk mengambil peran IAM yang kemudian akan memungkinkan akses lintas akun ke Akun AWS tempat di mana akses darurat diperlukan. Kami sarankan Anda untuk membuat pengguna sesedikit mungkin dan menetapkan masing-masing pengguna ke satu administrator darurat. Selama keadaan darurat, pengguna administrator darurat masuk ke akun akses darurat dengan menggunakan kata sandi dan kode token MFA mereka, beralih ke peran IAM akses darurat yang ada di akun darurat, dan pada akhirnya beralih ke peran IAM akses darurat yang ada di akun beban kerja untuk melakukan tindakan perubahan darurat. Kelebihan pendekatan ini adalah setiap pengguna IAM ditugaskan ke satu administrator darurat dan Anda dapat mengetahui pengguna mana yang masuk dengan melakukan peninjauan pada peristiwa CloudTrail. Kelemahan pendekatan ini adalah Anda harus mempertahankan beberapa pengguna IAM dengan kata sandi berumur panjang dan token MFA yang sudah dikaitkan.
+ Anda dapat menggunakan [pengguna root Akun AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) akses darurat untuk masuk ke akun akses darurat, mengambil peran IAM untuk akses darurat, dan mengambil peran lintas akun yang ada di akun beban kerja. Kami merekomendasikan Anda untuk menggunakan pengaturan kata sandi yang kuat dan beberapa token MFA untuk pengguna root tersebut. Kami juga menyarankan Anda untuk menyimpan kata sandi dan token MFA di sebuah brankas kredensial korporasi yang aman yang memberlakukan autentikasi dan otorisasi yang kuat. Anda harus mengamankan kata sandi dan faktor pengaturan ulang token MFA: atur alamat email akun ke sebuah daftar distribusi email yang dipantau oleh administrator keamanan cloud Anda, dan atur nomor telepon akun ke nomor telepon bersama yang juga dipantau oleh administrator keamanan. Keunggulan pendekatan ini adalah bahwa hanya ada satu set kredensial pengguna root yang harus dikelola. Kelemahan pendekatan ini adalah karena ini merupakan pengguna bersama, maka ada beberapa administrator yang memiliki kemampuan untuk masuk sebagai pengguna root. Anda harus melakukan audit terhadap peristiwa log brankas korporasi Anda untuk mengidentifikasi administrator mana yang menggunakan kata sandi pengguna root.
**Mode Kegagalan 2: Konfigurasi penyedia identitas di AWS sudah dimodifikasi atau telah kedaluwarsa**
Agar pengguna tenaga kerja Anda dapat melakukan federasi ke Akun AWS, Anda dapat mengonfigurasi Pusat Identitas IAM dengan penyedia identitas eksternal atau membuat sebuah Penyedia Identitas IAM ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). Biasanya, Anda melakukan konfigurasi dengan mengimpor dokumen XML metadata SAML yang disediakan oleh penyedia identitas Anda. Dokumen metadata XML tersebut menyertakan sebuah sertifikat X.509 yang sesuai dengan kunci privat yang digunakan oleh penyedia identitas untuk menandatangani pernyataan SAML-nya.
Konfigurasi di sisi AWS ini dapat diubah atau dihapus secara tidak sengaja oleh seorang administrator. Dalam skenario lain, sertifikat X.509 yang diimpor ke dalam AWS dapat kedaluwarsa dan XML metadata yang baru yang memiliki sertifikat baru belum diimpor ke AWS. Kedua skenario ini dapat mengganggu federasi ke AWS untuk pengguna tenaga kerja Anda, dan hal ini akan mengakibatkan terjadinya sebuah keadaan darurat.
Dalam keadaan darurat seperti ini, Anda dapat memberikan akses ke AWS kepada administrator identitas Anda untuk memperbaiki masalah yang terjadi pada federasi tersebut. Misalnya, administrator identitas Anda menggunakan proses akses darurat untuk masuk ke Akun AWS akses darurat, beralih ke peran yang ada di akun administrator Pusat Identitas, dan kemudian memperbarui konfigurasi penyedia identitas eksternal dengan mengimpor dokumen XML metadata SAML terbaru dari penyedia identitas Anda untuk mengaktifkan kembali federasi. Setelah federasi selesai diperbaiki, pengguna tenaga kerja Anda kemudian melanjutkan penggunaan proses operasi normal untuk melakukan federasi ke akun beban kerja mereka.
Anda dapat mengikuti pendekatan-pendekatan yang diuraikan dalam Mode Kegagalan 1 sebelumnya untuk membuat sebuah proses akses darurat. Anda dapat memberikan hak akses paling rendah kepada administrator identitas Anda sehingga hanya bisa mengakses akun administrator Pusat Identitas dan melakukan tindakan pada Pusat Identitas di akun tersebut.
**Mode Kegagalan 3: Gangguan Pusat Identitas**
Apabila terjadi gangguan Wilayah AWS atau terjadi peristiwa yang tidak semestinya pada Pusat Identitas IAM, kami sarankan Anda untuk menyiapkan konfigurasi yang dapat Anda gunakan untuk menyediakan akses sementara ke Konsol Manajemen AWS.
Proses akses darurat tersebut menggunakan federasi langsung dari penyedia identitas Anda ke IAM dalam yang ada dalam sebuah akun darurat. Untuk mendapatkan detail tentang proses dan pertimbangan desain, silakan lihat [Mengatur akses darurat ke Konsol Manajemen AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html).
### Langkah-langkah implementasi
**Langkah-langkah umum untuk semua mode kegagalan**
+ Buatlah sebuah Akun AWS yang ditujukan khusus untuk proses akses darurat. Di awal, buatlah sumber daya IAM yang dibutuhkan di dalam akun tersebut, seperti peran IAM atau pengguna IAM, dan Penyedia Identitas IAM opsional. Selain itu, buatlah di awal, peran IAM lintas akun di dalam Akun AWS beban kerja yang memiliki hubungan kepercayaan dengan peran IAM yang sesuai di akun akses darurat tersebut. Anda dapat menggunakan [CloudFormation StackSets dengan AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) untuk membuat sumber daya tersebut di akun anggota yang ada dalam organisasi Anda.
+ Buatlah [kebijakan kontrol layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) AWS Organizations untuk menyangkal penghapusan dan modifikasi peran IAM lintas akun yang ada dalam anggota Akun AWS.
+ Aktifkan CloudTrail untuk Akun AWS akses darurat dan kirimkan peristiwa jejak ke bucket S3 pusat yang ada di Akun AWS pengumpulan log Anda. Jika Anda menggunakan AWS Control Tower untuk menyiapkan dan mengatur lingkungan multi-akun AWS Anda, maka setiap akun yang Anda buat dengan menggunakan AWS Control Tower atau Anda daftarkan di AWS Control Tower akan memiliki CloudTrail yang diaktifkan secara default dan dikirim ke bucket S3 dalam sebuah Akun AWS arsip log khusus.
+ Pantau aktivitas yang terjadi di akun akses darurat dengan membuat aturan EventBridge yang cocok saat login konsol dan aktivitas API berdasarkan peran IAM darurat. Kirimkan notifikasi ke pusat operasi keamanan Anda ketika ada aktivitas yang terjadi di luar peristiwa darurat yang sedang berlangsung yang terlacak dalam sistem manajemen insiden Anda.
**Langkah-langkah tambahan untuk Mode Kegagalan 1: Penyedia identitas yang digunakan untuk melakukan federasi ke AWS tidak tersedia dan Mode Kegagalan 2: Konfigurasi penyedia identitas di AWS sudah dimodifikasi atau telah kedaluwarsa**
+ Buatlah sumber daya di awal tergantung pada mekanisme yang Anda pilih untuk akses darurat:
+ **Menggunakan pengguna IAM:** buatlah pengguna IAM di awal dengan kata sandi yang kuat serta perangkat MFA yang dikaitkan.
+ **Menggunakan pengguna root akun darurat:** konfigurasikan pengguna root dengan kata sandi yang kuat dan simpan kata sandi tersebut di dalam brankas kredensial korporasi Anda. Kaitkan beberapa perangkat MFA fisik dengan pengguna root dan simpan perangkat tersebut di lokasi yang dapat diakses dengan cepat oleh anggota tim administrator darurat Anda.
**Langkah-langkah tambahan untuk Mode Kegagalan 3: Gangguan pusat identitas**
+ Sebagaimana diuraikan dalam langkah [Siapkan akses darurat ke Konsol Manajemen AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html), di Akun AWS akses darurat, buat sebuah Penyedia Identitas IAM untuk mengaktifkan federasi SAML langsung dari penyedia identitas Anda.
+ Buat grup operasi darurat di IdP Anda tanpa anggota.
+ Buat peran IAM yang sesuai dengan grup operasi darurat yang ada di akun akses darurat.
## Sumber daya
**Praktik terbaik Well-Architected terkait:**
+ [SEC02-BP04 Mengandalkan penyedia identitas tersentralisasi](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
+ [SEC03-BP02 Memberikan hak akses paling rendah](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)
+ [SEC10-BP02 Membuat rencana manajemen insiden](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
+ [SEC10-BP07 Menjalankan game day](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)
**Dokumen terkait:**
+ [Menyiapkan akses darurat ke Konsol Manajemen AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)
+ [Mengaktifkan pengguna gabungan SAML 2.0 untuk mengakses Konsol Manajemen AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)
+ [Akses pecah kaca](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Video terkait:**
+ [AWS re:Invent 2022 - Menyederhanakan akses tenaga kerja Anda dengan Pusat Identitas IAM](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Inforce 2022 - Pembahasan mendalam tentang AWS Identity and Access Management (IAM)](https://youtu.be/YMj33ToS8cI)
**Contoh terkait:**
+ [AWS Peran Pecah Kaca](https://github.com/awslabs/aws-break-glass-role)
+ [AWS Kerangka kerja playbook pelanggan](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Contoh playbook respons insiden](https://github.com/aws-samples/aws-incident-response-playbooks)
# SEC03-BP04 Mengurangi izin secara terus-menerus
Jika tim Anda telah menentukan akses yang diperlukan, maka Anda harus menghapus izin-izin yang tidak diperlukan dan menetapkan proses peninjauan untuk mendapatkan izin hak akses paling rendah. Lakukan pemantauan secara terus-menerus dan hapus identitas serta izin-izin yang tidak diperlukan, baik untuk akses manusia maupun mesin.
**Hasil yang diinginkan:** Kebijakan izin harus mematuhi prinsip hak akses paling rendah. Setelah penetapan tugas dan peran pekerjaan sudah menjadi lebih baik, kebijakan izin Anda perlu ditinjau untuk menghapus izin-izin yang tidak perlu. Pendekatan ini mempersempit cakupan dampak akibat terjadinya kebocoran kredensial secara tidak sengaja, atau karena diakses tanpa otorisasi.
**Anti-pola umum:**
+ Memberikan izin administrator kepada para pengguna secara default.
+ Membuat kebijakan yang terlalu permisif, tetapi tanpa memberikan hak istimewa administrator penuh.
+ Menyimpan kebijakan izin meski sudah tidak diperlukan lagi.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Setelah tim dan proyek mulai, kebijakan izin permisif mungkin digunakan untuk menumbuhkan banyak inovasi dan ketangkasan. Misalnya, di dalam sebuah lingkungan pengembangan atau pengujian, developer dapat diberi akses ke berbagai layanan AWS. Sebaiknya evaluasi akses secara terus-menerus dan batasi akses hanya untuk layanan dan tindakan layanan yang diperlukan untuk menyelesaikan tugas saat ini. Sebaiknya evaluasi ini dilakukan untuk identitas manusia maupun mesin. Identitas mesin, sering disebut sebagai akun layanan atau sistem, adalah identitas yang memberikan AWS akses ke aplikasi atau server. Akses ini penting, terutama dalam sebuah lingkungan produksi, yang apabila izinnya terlalu permisif, maka dampaknya bisa begitu luas dan berpotensi mengekspos data konsumen.
AWS menyediakan berbagai metode untuk membantu Anda mengidentifikasi pengguna, peran, izin, dan kredensial yang tidak diperlukan. AWS juga dapat membantu Anda dalam menganalisis aktivitas akses yang dilakukan oleh pengguna IAM dan peran IAM, termasuk kunci akses terkait, dan akses ke sumber daya AWS, misalnya objek di bucket Amazon S3. Pembuatan kebijakan AWS Identity and Access Management Access Analyzer dapat membantu Anda menciptakan kebijakan-kebijakan pembatasan izin berdasarkan layanan dan tindakan aktual yang berinteraksi dengan principal. [Kontrol akses berbasis atribut (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dapat membantu Anda untuk menyederhanakan pengelolaan izin, karena Anda dapat memberikan izin kepada para pengguna dengan menggunakan atribut mereka, alih-alih melampirkan kebijakan izin secara langsung ke masing-masing pengguna.
### Langkah-langkah implementasi
+ **Gunakan [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html):** IAM Access Analyzer akan membantu Anda untuk mengidentifikasi sumber daya yang ada di akun dan organisasi Anda, seperti bucket Amazon Simple Storage Service (Amazon S3) atau peran IAM, yang [digunakan bersama dengan sebuah entitas eksternal](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Gunakan [pembuatan kebijakan IAM Access Analyzer:](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)** Pembuatan kebijakan IAM Access Analyzer membantu Anda [membuat kebijakan izin yang sangat terperinci berdasarkan aktivitas akses pengguna IAM atau peran IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks).
+ **Uji izin di lingkungan yang lebih rendah sebelum produksi:** Mulailah dengan memanfaatkan [lingkungan sandbox dan pengembangan yang tidak begitu krusial](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/understanding-the-devops-environments.html) guna menguji izin yang diperlukan untuk berbagai fungsi pekerjaan menggunakan IAM Access Analyzer. Kemudian, secara bertahap perketat dan validasikan izin ini di seluruh lingkungan pengujian, jaminan kualitas, dan pementasan sebelum menerapkannya pada produksi. Lingkungan yang lebih rendah dapat memiliki izin yang lebih longgar pada awalnya karena kebijakan kontrol layanan (SCP) memberlakukan pagar pembatas dengan membatasi izin maksimum yang diberikan.
+ **Menentukan jangka waktu dan kebijakan penggunaan yang dapat diterima untuk pengguna IAM dan peran IAM:** Gunakan [stempel waktu yang terakhir diakses](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) untuk [mengidentifikasi pengguna dan peran yang tidak digunakan dan](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/) kemudian menghapusnya. Tinjau layanan dan tindakan informasi yang terakhir diakses untuk mengidentifikasi dan [masukkan izin dalam cakupan untuk pengguna dan peran tertentu](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Misalnya, Anda dapat menggunakan informasi yang terakhir diakses untuk mengidentifikasi tindakan Amazon S3 tertentu yang diperlukan oleh peran aplikasi dan membatasi akses hanya untuk tindakan-tindakan tersebut. Fitur informasi yang terakhir diakses tersedia di Konsol Manajemen AWS dan secara terprogram akan memungkinkan Anda untuk menggabungkannya ke dalam alur kerja infrastruktur dan alat-alat otomatis Anda.
+ **Pertimbangkan untuk [mencatat peristiwa data di AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html):** Secara default, CloudTrail tidak mencatat log peristiwa data seperti aktivitas tingkat objek Amazon S3 (misalnya, `GetObject` dan `DeleteObject`) atau aktivitas tabel Amazon DynamoDB (misalnya, `PutItem` dan `DeleteItem`). Pertimbangkan untuk mengaktifkan pencatatan log untuk peristiwa ini sehingga Anda bisa menentukan pengguna dan peran apa yang perlu mengakses objek Amazon S3 dan item tabel DynamoDB tertentu.
## Sumber daya
**Dokumen terkait:**
+ [Berikan hak akses paling rendah](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Hapus kredensial yang tidak perlu](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [ Apa itu AWS CloudTrail? ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [Bekerja dengan Kebijakan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [ Pencatatan log dan pemantauan DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ Menggunakan pencatatan log peristiwa CloudTrail untuk bucket dan objek Amazon S ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [ Mendapatkan laporan kredensial untuk akun Anda Akun AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**Video terkait:**
+ [Menjadi Master Kebijakan IAM dalam 60 Menit atau Kurang](https://youtu.be/YQsK4MtsELU)
+ [Pemisahan Tugas, Hak Akses Paling Rendah, Delegasi, dan CI/CD](https://youtu.be/3H0i7VyTu70)
+ [AWS re:Inforce 2022 - Pembahasan mendalam tentang AWS Identity and Access Management (IAM) ](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP05 Tentukan pagar pembatas izin untuk organisasi Anda
Gunakan pagar pembatas izin untuk mengurangi cakupan izin-izin yang tersedia yang dapat diberikan kepada principal. Rantai evaluasi kebijakan izin mencakup pagar pembatas yang digunakan untuk menentukan *izin efektif* principal saat membuat keputusan otorisasi. Anda dapat menentukan pagar pembatas dengan menggunakan pendekatan berbasis lapisan. Terapkan beberapa pagar pembatas secara meluas di seluruh organisasi Anda dan terapkan pagar pembatas lainnya secara terperinci ke sesi akses sementara.
**Hasil yang diinginkan:** Anda memiliki isolasi lingkungan yang jelas menggunakan Akun AWS terpisah. Kebijakan kontrol layanan (SCP) digunakan untuk menentukan pagar pembatas izin di tingkat organisasi. Pagar pembatas yang lebih meluas ditetapkan pada tingkat hierarki yang paling dekat dengan root organisasi Anda, dan pagar pembatas yang lebih ketat ditetapkan lebih dekat ke tingkat akun individual.
Jika didukung, kebijakan sumber daya akan menentukan kondisi yang harus dipenuhi oleh principal untuk mendapatkan akses ke sebuah sumber daya. Kebijakan sumber daya juga mengurangi cakupan dari serangkaian tindakan yang diizinkan, jika sesuai. Batasan izin diterapkan pada principal yang mengelola izin beban kerja, dengan mendelegasikan manajemen izin kepada pemilik beban kerja individual.
**Anti-pola umum:**
+ Membuat Akun AWS anggota dalam suatu [Organisasi AWS](https://aws.amazon.com/organizations/), tetapi tidak menggunakan SCP untuk membatasi penggunaan dan izin yang tersedia untuk kredensial root-nya.
+ Menetapkan izin berdasarkan hak akses paling rendah, tetapi tidak menerapkan pagar pembatas pada kumpulan izin maksimum yang dapat diberikan.
+ Mengandalkan fondasi *penolakan implisit AWS IAM* untuk membatasi izin, yang meyakini bahwa kebijakan tidak akan memberikan *izin eksplisit* yang tidak diinginkan.
+ Menjalankan beberapa lingkungan beban kerja dalam lingkungan Akun AWS yang sama, dan kemudian mengandalkan berbagai mekanisme, seperti VPC, tanda, atau kebijakan sumber daya untuk memberlakukan batasan izin.
**Manfaat menjalankan praktik terbaik ini:** Pagar pembatas izin akan membantu Anda untuk membangun keyakinan bahwa izin yang tidak diinginkan tidak dapat diberikan, bahkan ketika kebijakan izin mencoba melakukannya. Hal ini dapat menyederhanakan penentuan dan pengelolaan izin dengan mengurangi cakupan maksimum izin yang perlu dipertimbangkan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Sebaiknya Anda gunakan pendekatan berbasis lapisan untuk menentukan pagar pembatas izin bagi organisasi Anda. Pendekatan ini secara sistematis akan mengurangi izin maksimum yang mungkin digunakan saat lapisan tambahan diterapkan. Hal ini akan membantu Anda memberikan akses berdasarkan prinsip hak akses paling rendah, sehingga itu akan mengurangi risiko akses yang tidak diinginkan karena terjadinya kesalahan konfigurasi kebijakan.
Langkah pertama untuk membuat pagar pembatas izin adalah mengisolasi beban kerja dan lingkungan Anda ke dalam Akun AWS terpisah. Principal dari satu akun tidak dapat mengakses sumber daya yang ada di akun lain tanpa izin eksplisit untuk melakukannya, bahkan ketika kedua akun berada di organisasi AWS yang sama atau di bawah [unit organisasi (OU)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) yang sama. Anda dapat menggunakan OU untuk mengelompokkan akun-akun yang ingin Anda kelola sebagai satu unit tunggal.
Langkah selanjutnya adalah mengurangi izin maksimum yang dapat Anda berikan kepada principal yang ada dalam akun anggota di organisasi Anda. Anda dapat menggunakan [kebijakan kontrol layanan (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) untuk tujuan ini, yang dapat Anda terapkan pada sebuah OU atau akun. SCP dapat memberlakukan kontrol akses umum, seperti membatasi akses ke Wilayah AWS tertentu, dan hal ini akan membantu mencegah sumber daya agar tidak dihapus, atau menonaktifkan tindakan layanan yang berpotensi berisiko. SCP yang Anda terapkan ke root organisasi Anda hanya akan memengaruhi akun-akun anggotanya saja, dan tidak akan berpengaruh pada akun manajemen. SCP hanya mengatur principal yang ada dalam organisasi Anda. SCP Anda tidak mengatur principal yang ada di luar organisasi Anda yang mengakses sumber daya Anda.
Jika Anda menggunakan [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html), Anda dapat memanfaatkan [kontrol](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work) dan [zona landasannya](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) sebagai dasar untuk pagar pembatas izin dan lingkungan multi-akun Anda. Zona landasan menyediakan lingkungan dasar yang telah dikonfigurasi sebelumnya dan aman dengan akun terpisah untuk beban kerja dan aplikasi yang berbeda. Pagar pembatas memberlakukan kontrol wajib seputar keamanan, operasi, dan kepatuhan melalui kombinasi Kebijakan Kontrol Layanan (SCP), aturan AWS Config, dan konfigurasi lainnya. Namun, saat menggunakan pagar pembatas dan zona landasan Control Tower bersama SCP Organisasi kustom, sangat penting untuk mengikuti praktik terbaik yang diuraikan dalam dokumentasi AWS untuk menghindari konflik dan memastikan tata kelola yang tepat. Lihat [panduan AWS Control Tower untuk AWS Organizations](https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html) guna mengetahui rekomendasi terperinci tentang pengelolaan SCP, akun, dan unit organisasi (OU) dalam lingkungan Control Tower.
Dengan mematuhi pedoman ini, Anda dapat secara efektif memanfaatkan pagar pembatas, zona landasan, dan SCP kustom Control Tower sambil mengurangi potensi konflik serta memastikan tata kelola dan kontrol yang tepat atas lingkungan AWS multi-akun Anda.
Langkah selanjutnya adalah menggunakan [kebijakan sumber daya IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based) untuk mencakup tindakan-tindakan yang tersedia yang dapat diambil pada sumber daya yang mereka atur, bersama dengan kondisi apa pun yang harus dipenuhi oleh principal. Ini bisa berupa memungkinkan semua tindakan selama principal adalah bagian dari organisasi Anda (menggunakan [kunci kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgId), atau sedetail hanya mengizinkan tindakan tertentu dengan peran IAM tertentu. Anda dapat mengambil pendekatan serupa terhadap kondisi dalam kebijakan kepercayaan peran IAM. Jika kebijakan kepercayaan sumber daya atau peran secara eksplisit menyebutkan suatu principal di akun yang sama sebagai peran atau sumber daya yang diaturnya, principal tersebut tidak perlu dilampiri dengan kebijakan IAM yang memberikan izin yang sama. Jika principal berada di akun yang berbeda dari sumber daya, maka principal memang perlu dilampiri dengan kebijakan IAM yang memberikan izin tersebut.
Sering kali, sebuah tim beban kerja ingin mengelola izin yang dibutuhkan beban oleh kerja mereka. Hal ini mungkin mengharuskan mereka membuat peran IAM dan kebijakan izin IAM yang baru. Anda dapat merekam cakupan maksimum izin yang boleh diberikan tim dalam [batasan izin IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html), dan mengaitkan dokumen ini ke peran IAM yang kemudian dapat digunakan tim untuk mengelola peran IAM dan izin mereka. Pendekatan ini dapat memberi mereka fleksibilitas untuk menyelesaikan pekerjaan mereka sambil memitigasi risiko yang timbul karena memiliki akses administratif.
Langkah yang lebih terperinci adalah menerapkan teknik *manajemen akses istimewa* (PAM) dan *manajemen akses tinggi sementara* (TEAM). Salah satu contoh PAM adalah mewajibkan principal untuk melakukan autentikasi multi-faktor sebelum mengambil tindakan yang memerlukan hak akses istimewa. Untuk informasi selengkapnya, lihat [Mengonfigurasi akses API yang dilindungi MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html). TEAM memerlukan sebuah solusi yang mengelola persetujuan dan jangka waktu dari dan hingga kapan principal diizinkan memiliki akses yang ditingkatkan. Salah satu pendekatannya adalah menambahkan principal untuk sementara ke kebijakan kepercayaan peran untuk peran IAM yang memiliki akses yang ditingkatkan. Pendekatan lain adalah, dalam operasi normal, mengurangi izin yang diberikan kepada principal oleh peran IAM dengan menggunakan [kebijakan sesi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session), dan kemudian mencabut sementara pembatasan ini selama jendela waktu yang disetujui. Untuk mempelajari lebih lanjut tentang solusi yang divalidasi oleh AWS dan mitra terpilih, lihat [Akses yang ditingkatkan sementara](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html).
### Langkah-langkah implementasi
1. Isolasikan beban kerja dan lingkungan Anda ke dalam Akun AWS terpisah.
1. Gunakan SCP untuk mengurangi izin maksimum yang dapat diberikan kepada principal yang ada dalam akun anggota di organisasi Anda.
1. Saat mendefinisikan SCP untuk mengurangi kumpulan izin maksimum yang dapat diberikan kepada pengguna utama dalam akun anggota organisasi Anda, Anda dapat memilih antara pendekatan *daftar izinkan* atau *daftar tolak*. Strategi daftar izinkan secara eksplisit menentukan akses yang diizinkan dan secara implisit memblokir semua akses lainnya. Strategi daftar tolak secara eksplisit menentukan akses yang tidak diizinkan dan mengizinkan semua akses lainnya secara default. Kedua strategi ini memiliki kelebihan dan kompromi masing-masing, dan pilihan yang tepat akan tergantung pada persyaratan dan model risiko spesifik organisasi Anda. Untuk detail selengkapnya, lihat [Strategi untuk menggunakan SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html).
1. Selain itu, tinjau [contoh kebijakan kontrol layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) untuk memahami cara menyusun SCP secara efektif.
1. Gunakan kebijakan sumber daya IAM untuk mengurangi cakupan dan menentukan kondisi untuk tindakan yang diizinkan pada sumber daya. Gunakan kondisi dalam kebijakan kepercayaan peran IAM untuk membuat batasan pada pengambilan peran.
1. Tetapkan batasan izin IAM ke peran IAM yang kemudian dapat digunakan tim beban kerja untuk mengelola peran IAM dan izin IAM beban kerja mereka sendiri.
1. Evaluasi solusi PAM dan TEAM berdasarkan kebutuhan Anda.
## Sumber daya
**Dokumen terkait:**
+ [Perimeter data pada AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/)
+ [Tetapkan pagar pembatas izin dengan menggunakan perimeter data](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html)
+ [Logika evaluasi kebijakan](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)
**Contoh terkait:**
+ [Contoh kebijakan kontrol layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
**Alat terkait:**
+ [AWS Solusi : Manajemen Akses Tinggi Sementara](https://aws-samples.github.io/iam-identity-center-team/)
+ [Solusi mitra keamanan tervalidasi untuk TEAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)
# SEC03-BP06 Mengelola akses berdasarkan siklus hidup
Lakukan pemantauan dan penyesuaian terhadap izin-izin yang diberikan kepada para principal Anda (pengguna, peran, dan grup) di sepanjang siklus hidupnya dalam organisasi Anda. Sesuaikan keanggotaan grup jika pengguna berganti peran, dan hapus akses saat seorang pengguna meninggalkan organisasi.
**Hasil yang diinginkan:** Anda melakukan pemantauan dan menyesuaikan izin sepanjang siklus hidup principal yang ada dalam organisasi, mengurangi risiko hak akses istimewa yang tidak perlu. Anda memberikan akses yang sesuai saat membuat pengguna. Anda mengubah akses saat tanggung jawab pengguna berubah, dan Anda menghapus akses ketika pengguna tersebut tidak lagi aktif atau telah meninggalkan organisasi. Anda mengelola perubahan yang terjadi pada pengguna, peran, dan grup secara terpusat. Anda menggunakan otomatisasi untuk menyebarkan perubahan-perubahan ke lingkungan AWS Anda.
**Anti-pola umum:**
+ Memberikan hak akses yang berlebihan atau luas ke identitas di awal, yang melebihi hak akses yang awalnya diperlukan.
+ Tidak meninjau dan menyesuaikan hak akses saat peran dan tanggung jawab identitas berubah dari waktu ke waktu.
+ Membiarkan identitas yang tidak aktif atau sudah dihentikan masih memiliki hak akses yang aktif. Hal ini akan meningkatkan risiko akses yang tidak sah.
+ Tidak memanfaatkan otomatisasi untuk mengelola siklus hidup identitas.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Kelola dan sesuaikan secara cermat hak akses yang Anda berikan kepada identitas (seperti pengguna, peran, grup) di sepanjang siklus hidup mereka. Siklus hidup ini mencakup fase onboarding awal, perubahan peran dan tanggung jawab yang berkelanjutan, dan akhirnya offboarding atau penghentian. Lakukan pengelolaan akses secara proaktif berdasarkan tahap siklus hidup untuk mempertahankan tingkat akses yang sesuai. Patuhi prinsip hak akses paling rendah untuk mengurangi munculnya risiko hak akses yang berlebihan atau tidak perlu.
Anda dapat mengelola siklus hidup pengguna IAM secara langsung dalam Akun AWS, ataupun melalui federasi dari penyedia identitas tenaga kerja Anda ke [Pusat Identitas IAM AWS](https://aws.amazon.com/iam/identity-center/). Untuk pengguna IAM, Anda dapat membuat, memodifikasi, dan menghapus pengguna dan izin terkait mereka yang ada dalam Akun AWS. Untuk pengguna gabungan (federated user), Anda dapat menggunakan Pusat Identitas IAM untuk mengelola siklus hidup mereka dengan menyinkronkan informasi pengguna dan grup dari penyedia identitas organisasi Anda dengan menggunakan protokol [System for Cross-domain Identity Management](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) (SCIM).
SCIM adalah sebuah protokol standar terbuka untuk penyediaan dan penghapusan penyediaan identitas pengguna otomatis di berbagai sistem. Dengan mengintegrasikan penyedia identitas Anda dengan Pusat Identitas IAM dengan menggunakan SCIM, Anda dapat secara otomatis melakukan sinkronisasi informasi pengguna dan grup, membantu memvalidasi bahwa hak akses diberikan, dimodifikasi, atau dicabut berdasarkan perubahan sumber identitas otoritatif yang ada di organisasi Anda.
Ketika peran dan tanggung jawab karyawan berubah dalam organisasi Anda, sesuaikan hak akses mereka sesuai keperluan. Anda dapat menggunakan kumpulan izin Pusat Identitas IAM untuk menentukan peran atau tanggung jawab pekerjaan yang berbeda-beda dan kemudian mengaitkannya dengan kebijakan IAM dan izin IAM yang sesuai. Saat peran seorang karyawan berubah, Anda dapat memperbarui kumpulan izin yang ditetapkan padanya untuk menyesuaikan dengan tanggung jawab baru mereka. Lakukan verifikasi bahwa mereka memiliki akses yang diperlukan dan sekaligus mematuhi prinsip hak akses paling rendah.
### Langkah-langkah implementasi
1. Tentukan dan dokumentasikan proses siklus hidup manajemen akses, termasuk prosedur-prosedur yang harus dilakukan untuk memberikan akses awal, peninjauan berkala, dan offboarding.
1. Implementasikan [peran IAM, grup, dan batasan izin](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) untuk mengelola akses secara kolektif dan memberlakukan tingkat akses maksimum yang diizinkan.
1. Berintegrasi dengan sebuah [penyedia identitas terfederasi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) (seperti Microsoft Active Directory, Okta, Ping Identity) sebagai sumber otoritatif untuk informasi pengguna dan grup menggunakan Pusat Identitas IAM.
1. Gunakan protokol [SCIM](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) untuk melakukan sinkronisasi informasi pengguna dan grup dari penyedia identitas ke Penyimpanan Identitas Pusat Identitas IAM.
1. Buat [kumpulan izin](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) di Pusat Identitas IAM yang merepresentasikan peran atau tanggung jawab pekerjaan yang berbeda-beda dalam organisasi Anda. Tentukan kebijakan IAM dan izin IAM yang sesuai untuk masing-masing kumpulan izin.
1. Implementasikan peninjauan akses secara rutin, pencabutan akses yang cepat, dan peningkatan berkelanjutan terhadap proses siklus hidup manajemen akses.
1. Berikan pelatihan dan pengetahuan kepada karyawan tentang praktik terbaik manajemen akses.
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [SEC02-BP04 Mengandalkan penyedia identitas tersentralisasi](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
**Dokumen terkait:**
+ [Kelola sumber identitas Anda](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)
+ [Kelola identitas di Pusat Identitas IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [Menggunakan AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [Pembuatan kebijakan IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
**Video terkait:**
+ [AWS re:Inforce 2023 - Kelola akses tambahan sementara dengan Pusat Identitas Pusat Identitas IAM AWS](https://www.youtube.com/watch?v=a1Na2G7TTQ0)
+ [AWS re:invent 2022 - Menyederhanakan akses tenaga kerja Anda dengan Pusat Identitas IAM](https://www.youtube.com/watch?v=TvQN4OdR_0Y&t=444s)
+ [AWS re:invent 2022 - Memanfaatkan kekuatan kebijakan IAM & mengendalikan izin dengan Access Analyzer](https://www.youtube.com/watch?v=x-Kh8hKVX74&list=PL2yQDdvlhXf8bvQJuSP1DQ8vu75jdttlM&index=11)
# SEC03-BP07 Menganalisis akses publik dan lintas akun
Pantau secara terus-menerus temuan yang menyoroti akses lintas akun dan publik. Kurangi akses publik dan akses lintas akun hanya ke sumber daya yang memerlukan akses ini.
**Hasil yang diinginkan:** Mengetahui sumber daya AWS Anda yang mana yang dibagikan dan dengan siapa. Lakukan pemantauan dan audit secara terus-menerus terhadap sumber daya bersama untuk memastikan bahwa sumber daya tersebut hanya dibagikan kepada principal yang sah.
**Anti-pola umum:**
+ Tidak menyimpan sebuah inventaris sumber daya bersama.
+ Tidak mengikuti sebuah proses persetujuan akses lintas akun atau publik ke sumber daya.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Rendah
## Panduan implementasi
Jika akun Anda berada di AWS Organizations, maka Anda dapat memberikan akses sumber daya ke seluruh organisasi, unit organisasi tertentu, atau masing-masing akun individu. Jika akun Anda bukan merupakan anggota suatu organisasi, maka Anda dapat berbagi sumber daya dengan akun individu. Anda dapat memberikan akses lintas akun secara langsung dengan menggunakan kebijakan berbasis sumber daya — misalnya, kebijakan [bucket Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) — atau dengan mengizinkan principal di akun lain untuk mengambil peran IAM di akun Anda. Saat menggunakan kebijakan sumber daya, verifikasi bahwa akses tersebut hanya diberikan kepada principal yang sah. Tentukan sebuah proses untuk menyetujui semua sumber daya yang diperlukan untuk tersedia secara publik.
[AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) menggunakan [keamanan yang dapat dibuktikan](https://aws.amazon.com/security/provable-security/) untuk mengidentifikasi semua jalur akses ke sumber daya dari luar akun tersebut. Keamanan tersebut akan meninjau kebijakan sumber daya secara terus-menerus, dan melaporkan temuan akses lintas akun dan publik untuk memudahkan Anda dalam menganalisis potensi akses yang meluas. Pertimbangkan untuk mengonfigurasi IAM Access Analyzer dengan AWS Organizations untuk memastikan Anda memiliki visibilitas tentang semua akun Anda. IAM Access Analyzer juga memungkinkan Anda untuk [melihat pratinjau temuan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html) sebelum melakukan deployment atas izin sumber daya. Hal ini akan memungkinkan Anda untuk memvalidasi bahwa perubahan kebijakan hanya memberikan akses lintas akun dan publik yang benar-benar diinginkan ke sumber daya Anda. Saat merancang untuk akses multi-akun, Anda dapat menggunakan [kebijakan kepercayaan](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) untuk mengontrol dalam kasus apa sebuah peran bisa diambil. Misalnya, Anda dapat menggunakan [kunci kondisi `PrincipalOrgId` untuk menolak upaya pengambilan peran dari luar AWS Organizations Anda](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/).
[AWS Config dapat melaporkan sumber daya](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) yang salah konfigurasi, dan melalui pemeriksaan kebijakan AWS Config, dapat mendeteksi sumber daya yang memiliki akses publik yang dikonfigurasi. Layanan-layanan seperti [AWS Control Tower](https://aws.amazon.com/controltower/) dan [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) menyederhanakan deployment pemeriksaan dan batasan pengaman di seluruh AWS Organizations untuk mengidentifikasi dan memperbaiki sumber daya yang terpapar publik. Misalnya, AWS Control Tower memiliki sebuah pagar pembatas terkelola yang dapat mendeteksi jika ada [snapshot Amazon EBS yang dapat dipulihkan oleh Akun AWS](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html).
### Langkah-langkah implementasi
+ **Pertimbangkan untuk menggunakan[AWS Config for AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html):** AWS Config akan memungkinkan Anda mengumpulkan temuan dari beberapa akun dalam sebuah AWS Organizations ke akun administrator yang didelegasikan. Ini akan memberikan tampilan yang komprehensif, dan memungkinkan Anda untuk [melakukan deployment terhadap Aturan AWS Config di seluruh akun untuk mendeteksi sumber daya yang dapat diakses publik](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html).
+ **Konfigurasikan AWS Identity and Access Management Access Analyzer:** IAM Access Analyzer akan membantu Anda mengidentifikasi sumber daya di akun dan organisasi Anda, seperti bucket Amazon S3 atau peran IAM yang [dibagikan ke entitas eksternal](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Gunakan remediasi otomatis AWS Config untuk merespons perubahan konfigurasi akses publik bucket Amazon S3:** [Anda dapat secara otomatis mengaktifkan pengaturan blokir akses publik untuk bucket Amazon S3](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
+ **Terapkan pemantauan dan peringatan untuk mengidentifikasi apakah bucket Amazon S3 telah menjadi publik:** Anda harus memiliki [pemantauan dan peringatan](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/) yang tersedia untuk mengidentifikasi kapan Blokir Akses Publik Amazon S3 dimatikan, dan apakah bucket Amazon S3 sudah publik atau tidak. Selain itu, jika Anda menggunakan AWS Organizations, Anda dapat membuat sebuah [kebijakan kontrol layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) yang mencegah perubahan pada kebijakan akses publik Amazon S3. [AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) akan memeriksa bucket Amazon S3 yang memiliki izin akses terbuka. Izin bucket yang memberikan, mengunggah, atau menghapus akses ke semua orang akan menciptakan potensi masalah keamanan dengan mengizinkan siapa pun untuk menambahkan, mengubah, atau menghapus item yang dalam sebuah bucket. Pemeriksaan Trusted Advisor memeriksa izin bucket eksplisit dan kebijakan-kebijakan bucket terkait yang mungkin mengganti izin bucket. Anda juga dapat menggunakan AWS Config untuk memantau bucket Amazon S3 Anda untuk akses publik. Untuk informasi selengkapnya, lihat [Cara Menggunakan AWS Config untuk Memantau dan Merespons Bucket Amazon S3 yang Memungkinkan Akses Publik](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
Saat meninjau kontrol akses untuk bucket Amazon S3, penting untuk mempertimbangkan sifat data yang tersimpan di dalamnya. [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) adalah layanan yang dirancang untuk membantu Anda menemukan dan melindungi data sensitif, seperti Informasi Pengenal Pribadi (PII), Informasi Kesehatan yang Dilindungi (PHI), dan kredensial seperti kunci pribadi atau kunci akses AWS.
## Sumber daya
**Dokumen terkait:**
+ [Menggunakan AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [Pustaka kontrol AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+ [Standar Praktik Terbaik Keamanan Dasar AWS](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+ [Aturan Terkelola AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)
+ [Referensi pemeriksaan AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
+ [ Memantau hasil pemeriksaan AWS Trusted Advisor dengan Amazon EventBridge ](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [ Mengelola Aturan AWS Config di Semua Akun di Organisasi Anda ](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config dan AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)
+ [ Membuat AMI Anda tersedia secara umum untuk digunakan di Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis)
**Video terkait:**
+ [Praktik Terbaik untuk mengamankan lingkungan multiakun Anda](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Memahami lebih dalam IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 Membagikan sumber daya secara aman dalam organisasi Anda
Seiring dengan meningkatnya jumlah beban kerja, Anda mungkin perlu membagikan akses ke sumber daya dalam beban kerja tersebut atau berulang kali menyediakan sumber daya itu di seluruh akun. Anda mungkin memiliki konsep untuk membagi lingkungan Anda dalam beberapa kelompok, seperti lingkungan pengembangan, pengujian, dan lingkungan produksi. Namun demikian, konsep pemisahan ini tidak akan membatasi Anda untuk berbagi secara aman. Dengan membagikan komponen-komponen yang tumpang tindih, Anda dapat mengurangi overhead operasional dan memungkinkan pengalaman yang konsisten tanpa harus menebak-nebak mengenai apa yang terlewatkan sekaligus membuat sumber daya yang sama berulang kali.
**Hasil yang diinginkan:** Mengurangi akses yang tidak diinginkan sekecil hingga sekecil mungkin dengan menggunakan metode yang aman untuk berbagi sumber daya dalam organisasi Anda, dan membantu inisiatif pencegahan kehilangan data Anda. Mengurangi overhead operasional daripada mengelola komponen satu per satu, akan mengurangi kesalahan yang diakibatkan oleh pembuatan komponen yang sama secara manual berulang kali, serta meningkatkan skalabilitas beban kerja. Anda dapat memperoleh manfaat dari pengurangan waktu hingga resolusi di skenario kegagalan multi-titik, dan meningkatkan keyakinan Anda dalam menentukan kapan sebuah komponen tidak diperlukan lagi. Untuk panduan preskriptif tentang cara melakukan analisis sumber daya bersama secara eksternal, silakan lihat [SEC03-BP07 Menganalisis akses publik dan lintas akun](sec_permissions_analyze_cross_account.md).
**Anti-pola umum:**
+ Tidak ada proses untuk melakukan pemantauan secara terus-menerus dan dan memberikan peringatan otomatis mengenai pembagian secara eksternal yang tidak terduga.
+ Tidak ada acuan terkait apa yang boleh dan tidak boleh dibagikan.
+ Kebijakan terbuka luas secara default, bukannya berbagi secara eksplisit ketika diperlukan.
+ Membuat sumber daya dasar yang tumpang tindih secara manual, saat diperlukan.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Rancang arsitektur pola dan kontrol akses Anda untuk mengelola penggunaan sumber daya yang dibagikan secara aman dan hanya dengan entitas-entitas yang tepercaya. Lakukan pemantauan terhadap sumber daya yang dibagikan dan peninjauan terhadap akses sumber daya yang dibagikan secara terus-menerus serta tetap waspada terhadap adanya pembagian yang tidak terduga atau tidak tepat. Tinjau [Analisis akses publik dan akses lintas akun](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) untuk membantu Anda menetapkan tata kelola untuk mengurangi akses eksternal hanya ke sumber daya yang memerlukannya, dan untuk membuat proses untuk melakukan pemantauan secara terus menerus dan memberi peringatan secara otomatis.
Berbagi lintas akun dalam AWS Organizations didukung oleh [sejumlah layanan AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html), seperti [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html), dan [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html). Layanan-layanan ini akan memungkinkan data untuk dibagikan ke akun pusat, dapat diakses dari akun pusat, atau mengelola sumber daya dan data dari akun pusat. Misalnya, AWS Security Hub CSPM dapat mentransfer temuan dari akun individu ke sebuah akun pusat sehingga Anda dapat melihat semua temuan. AWS Backup dapat melakukan pencadangan untuk sumber daya dan membagikannya ke seluruh akun. Anda dapat menggunakan [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) untuk berbagi sumber daya umum lainnya, seperti [subnet VPC dan lampiran Gateway Transit](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall), atau [Amazon SageMaker AI pipelines](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker).
Untuk membatasi akun Anda agar hanya berbagi sumber daya dalam organisasi Anda, gunakan [kebijakan kontrol layanan (SCP)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) untuk mencegah akses ke principal eksternal. Saat berbagi sumber daya, gabungkan kontrol berbasis identitas dan kontrol jaringan untuk [membuat perimeter data bagi organisasi Anda](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) guna membantu Anda melindungi dari akses yang tidak diinginkan. Perimeter data adalah kumpulan pagar pembatas preventif untuk membantu Anda memverifikasi bahwa hanya identitas yang Anda percaya saja yang mengakses sumber daya tepercaya dari jaringan yang dikenal. Kontrol ini akan menetapkan batas yang sesuai terkait sumber daya apa yang dapat dibagikan, serta mencegah dibagikannya atau bocornya sumber daya yang tidak semestinya terjadi. Misalnya, sebagai bagian dari perimeter data, Anda dapat menggunakan kebijakan titik akhir VPC dan kondisi `AWS:PrincipalOrgId` untuk memastikan identitas yang mengakses bucket Amazon S3 yang dimiliki organisasi Anda. Penting untuk dicatat bahwa [SCP tidak berlaku untuk peran terkait layanan atau principal layanan AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions).
Saat menggunakan Amazon S3, [matikan ACL untuk bucket Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) Anda dan gunakan kebijakan IAM untuk menentukan kontrol akses. Untuk [membatasi akses ke asal Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) dari [Amazon CloudFront](https://aws.amazon.com/cloudfront/), bermigrasilah dari identitas akses asal (OAI) ke kontrol akses asal (OAC) yang mendukung fitur tambahan termasuk enkripsi di sisi server dengan [AWS Key Management Service](https://aws.amazon.com/kms/).
Dalam beberapa kasus, Anda mungkin ingin mengizinkan pembagian sumber daya ke luar organisasi Anda atau memberikan pihak ketiga akses ke sumber daya Anda. Untuk panduan preskriptif tentang cara mengelola izin untuk berbagi sumber daya secara eksternal, lihat [Manajemen izin](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html).
### Langkah-langkah implementasi
1. **Gunakan AWS Organizations:** AWS Organizations adalah layanan manajemen akun yang akan memungkinkan Anda mengonsolidasikan beberapa Akun AWS ke dalam organisasi yang Anda buat dan kelola secara terpusat. Anda dapat mengelompokkan akun ke dalam unit organisasi (OU) dan melampirkan kebijakan-kebijakan yang berbeda ke setiap OU untuk membantu Anda memenuhi kebutuhan anggaran, keamanan, dan kepatuhan. Anda juga dapat mengontrol cara layanan kecerdasan buatan (AI) dan machine learning (ML) AWS mengumpulkan dan menyimpan data, serta menggunakan manajemen multiakun layanan-layanan AWS yang terintegrasi dengan Organisasi.
1. **Integrasikan AWS Organizations dengan layanan AWS:** Ketika Anda menggunakan sebuah layanan AWS untuk melakukan tugas atas nama Anda di akun anggota organisasi Anda, AWS Organizations akan membuat peran terkait layanan (SLR) IAM untuk layanan tersebut di setiap akun anggota. Anda harus mengelola akses tepercaya menggunakan Konsol Manajemen AWS, API AWS, atau AWS CLI. Untuk panduan preskriptif tentang cara mengaktifkan akses tepercaya, lihat [Menggunakan AWS Organizations dengan layanan AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) dan [layanan AWS lain yang dapat Anda gunakan dengan Organisasi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).
1. **Tetapkan perimeter data:** Perimeter data memberikan batas kepercayaan dan kepemilikan yang jelas. Di AWS, hal ini biasanya direpresentasikan sebagai organisasi AWS Anda yang dikelola oleh AWS Organizations, bersama dengan jaringan atau sistem on-premise yang mengakses sumber daya AWS Anda. Perimeter data bertujuan untuk memverifikasi bahwa akses diizinkan jika identitasnya dipercaya, sumber dayanya dipercaya, dan jaringannya dikenal. Namun, menetapkan perimeter data bukanlah pendekatan yang bisa digunakan untuk semua situasi. Evaluasi dan adopsi tujuan kontrol yang diuraikan dalam [laporan resmi Membangun Perimeter di AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/welcome.html) berdasarkan model dan persyaratan risiko keamanan spesifik Anda. Anda harus mempertimbangkan postur risiko yang Anda miliki dengan cermat dan menerapkan kontrol perimeter yang selaras dengan kebutuhan keamanan Anda.
1. **Gunakan berbagi sumber daya di layanan AWS dan terapkan pembatasan dengan sesuai:** Banyak layanan AWS memungkinkan Anda berbagi sumber daya dengan akun lain, atau menargetkan sumber daya di akun lain, seperti [Amazon Machine Image (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) dan [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html). Batasi API `ModifyImageAttribute` untuk menentukan akun tepercaya yang akan berbagi AMI. Tentukan kondisi `ram:RequestedAllowsExternalPrincipals` saat menggunakan AWS RAM untuk membatasi berbagi ke organisasi Anda saja, untuk membantu mencegah akses dari identitas yang tidak tepercaya. Untuk panduan dan pertimbangan preskriptif, lihat [Berbagi sumber daya dan target eksternal](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html).
1. **Gunakan AWS RAM untuk berbagi secara aman dengan sebuah akun atau dengan Akun AWS lainnya:** [AWS RAM](https://aws.amazon.com/ram/) akan membantu Anda secara aman membagikan sumber daya yang Anda buat kepada peran dan pengguna di akun Anda, serta dengan Akun AWS lainnya. Dalam lingkungan multiakun, AWS RAM akan memungkinkan Anda untuk membuat sumber daya satu kali dan membagikannya ke akun lain. Pendekatan ini membantu mengurangi overhead operasional sekaligus memberikan konsistensi, visibilitas, dan auditabilitas melalui integrasi dengan Amazon CloudWatch dan AWS CloudTrail, yang tidak Anda dapatkan saat menggunakan akses lintas akun.
Jika Anda memiliki sumber daya yang Anda bagikan sebelumnya dengan menggunakan kebijakan berbasis sumber daya, maka Anda dapat menggunakan [API `PromoteResourceShareCreatedFromPolicy`](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) atau yang setara untuk mempromosikan pembagian sumber daya ke pembagian sumber daya AWS RAM penuh.
Dalam beberapa kasus, Anda mungkin memerlukan beberapa langkah tambahan yang harus dilakukan untuk berbagi sumber daya. Misalnya, untuk membagikan snapshot terenkripsi, Anda perlu [membagikan kunci AWS KMS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key).
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [SEC03-BP07 Menganalisis akses publik dan lintas akun](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP09 Membagikan sumber daya secara aman kepada pihak ketiga](sec_permissions_share_securely_third_party.md)
+ [SEC05-BP01 Buat lapisan jaringan](sec_network_protection_create_layers.md)
**Dokumen terkait:**
+ [Pemilik bucket yang memberikan izin lintas akun untuk objek yang bukan miliknya](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [Cara menggunakan Kebijakan Kepercayaan dengan IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Membangun Perimeter Data di AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [Cara menggunakan ID eksternal saat memberikan pihak ketiga akses ke sumber daya AWS Anda](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Layanan AWS yang dapat Anda gunakan dengan AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [Membuat perimeter data pada AWS: Izinkan hanya identitas tepercaya saja yang bisa mengakses data perusahaan](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)
**Video terkait:**
+ [Akses Terperinci dengan AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [Mengamankan perimeter data Anda dengan titik akhir VPC](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ Membuat perimeter data di AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)
**Alat terkait:**
+ [ Contoh Kebijakan Perimeter Data ](https://github.com/aws-samples/data-perimeter-policy-examples)
# SEC03-BP09 Membagikan sumber daya secara aman kepada pihak ketiga
Keamanan lingkungan cloud tidak berhenti di organisasi Anda. Organisasi Anda mungkin menggunakan pihak ketiga untuk mengelola sebagian data Anda. Manajemen izin untuk sistem yang dikelola pihak ketiga harus mengikuti praktik akses sesuai kebutuhan dengan menggunakan prinsip hak akses paling rendah dengan kredensial sementara. Melalui kerja sama dengan pihak ketiga, Anda dapat mengurangi cakupan dampak dan risiko yang mungkin dimunculkan oleh akses yang tidak diinginkan.
**Hasil yang diinginkan:** Anda menghindari penggunaan kredensial AWS Identity and Access Management (IAM) jangka panjang seperti kunci akses dan kunci rahasia karena akan menimbulkan risiko keamanan jika disalahgunakan. Sebagai gantinya, Anda menggunakan peran IAM dan kredensial sementara untuk meningkatkan postur keamanan Anda dan meminimalkan overhead operasional untuk mengelola kredensial jangka panjang. Saat memberikan akses kepada pihak ketiga, Anda menggunakan pengidentifikasi unik universal (UUID) sebagai ID eksternal dalam kebijakan kepercayaan IAM dan menjaga kebijakan IAM terlampir pada peran di bawah kendali Anda untuk memastikan hak akses paling rendah. Untuk panduan preskriptif tentang menganalisis sumber daya yang dibagikan secara eksternal, lihat [SEC03-BP07 Menganalisis akses publik dan akses lintas akun](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html).
**Anti-pola umum:**
+ Menggunakan kebijakan kepercayaan IAM default tanpa persyaratan apa pun.
+ Menggunakan kunci akses dan kredensial IAM jangka panjang.
+ Menggunakan kembali ID eksternal.
**Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan:** Sedang
## Panduan implementasi
Anda mungkin ingin mengizinkan pembagian sumber daya ke luar AWS Organizations atau memberi pihak ketiga akses ke akun Anda. Misalnya, pihak ketiga mungkin menyediakan sebuah solusi pemantauan yang perlu mengakses sumber daya yang ada di akun Anda. Dalam kasus tersebut, buat peran lintas akun IAM yang hanya memiliki hak akses sesuai yang dibutuhkan oleh pihak ketiga tersebut. Selain itu, tentukan kebijakan kepercayaan dengan menggunakan [kondisi ID eksternal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). Saat menggunakan ID eksternal, Anda atau pihak ketiga dapat membuat sebuah ID unik untuk setiap pelanggan, pihak ketiga, atau penghunian. Setelah dibuat, ID unik tersebut tidak boleh dikontrol oleh siapa pun selain Anda. Pihak ketiga harus mengimplementasikan sebuah proses untuk memberikan ID eksternal melalui cara yang aman, dapat diaudit, dan diproduksi kembali.
Anda juga dapat menggunakan [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) untuk mengelola peran IAM untuk aplikasi di luar AWS yang menggunakan API AWS.
Hapus peran tersebut jika pihak ketiga sudah tidak perlu mengakses lingkungan Anda. Hindari menyediakan kredensial jangka panjang kepada pihak ketiga. Ketahui selalu layanan AWS lain yang mendukung fitur berbagi, seperti AWS Well-Architected Tool yang memungkinkan [berbagi beban kerja](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) dengan Akun AWS lain, dan [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) yang membantu Anda secara aman membagikan sumber daya AWS yang Anda miliki ke akun lain.
### Langkah-langkah implementasi
1. **Gunakan peran lintas akun untuk memberikan akses ke akun eksternal.** [Peran lintas akun](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) akan mengurangi jumlah informasi sensitif yang disimpan oleh akun eksternal dan pihak ketiga yang diperlukan untuk melayani pelanggan mereka. Peran lintas akun akan memungkinkan Anda memberikan akses ke sumber daya AWS yang ada di akun Anda kepada pihak ketiga secara aman, seperti Partner AWS atau akun-akun lainnya yang ada di organisasi Anda, dan Anda pun tetap dapat mengelola dan mengaudit akses tersebut. Pihak ketiga mungkin memberikan layanan kepada Anda dari sebuah infrastruktur hibrida atau menarik data ke lokasi di luar situs. [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) akan membantu Anda mengizinkan beban kerja pihak ketiga berinteraksi secara aman dengan beban kerja AWS Anda dan makin mengurangi kebutuhan akan kredensial jangka panjang.
Anda tidak boleh menggunakan kredensial jangka panjang atau kunci akses yang terkait dengan pengguna untuk menyediakan akses ke akun eksternal. Sebaiknya gunakan peran lintas akun untuk memberikan akses lintas akun sebagai gantinya.
1. **Lakukan uji tuntas dan pastikan akses aman untuk penyedia SaaS pihak ketiga.** Saat berbagi sumber daya dengan penyedia SaaS pihak ketiga, lakukan uji tuntas menyeluruh guna memastikan mereka memiliki pendekatan yang aman dan bertanggung jawab untuk mengakses sumber daya AWS Anda. Evaluasi model tanggung jawab bersama yang mereka miliki untuk memahami langkah-langkah keamanan yang mereka terapkan dan aspek keamanan yang menjadi tanggung jawab Anda. Pastikan bahwa penyedia SaaS memiliki proses yang aman dan dapat diaudit untuk mengakses sumber daya Anda, termasuk penggunaan [ID eksternal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) dan prinsip akses hak akses paling rendah. Penggunaan ID eksternal membantu mengatasi [masalah "confused deputy"](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/).
Implementasikan kontrol keamanan untuk memastikan akses yang aman dan kepatuhan terhadap prinsip hak akses paling rendah saat memberikan akses kepada penyedia SaaS pihak ketiga. Hal ini mungkin mencakup penggunaan ID eksternal, pengidentifikasi unik universal (UUID), dan kebijakan kepercayaan IAM yang membatasi akses hanya ke hal yang benar-benar diperlukan. Bekerjasamalah secara erat dengan penyedia SaaS untuk membangun mekanisme akses yang aman, tinjau akses mereka ke sumber daya AWS Anda secara teratur, dan lakukan audit untuk memastikan kepatuhan dengan persyaratan keamanan Anda.
1. **Menghilangkan kredensial jangka panjang yang disediakan pelanggan.** Hentikan penggunaan kredensial jangka panjang dan gunakan peran lintas akun atau IAM Roles Anywhere. Jika Anda harus menggunakan kredensial jangka panjang, buatlah sebuah rencana untuk bermigrasi ke akses berbasis peran. Untuk mendapatkan detail tentang cara mengelola kunci, lihat [Manajemen identitas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html). Selain itu, bekerjasamalah dengan tim Akun AWS Anda dan pihak ketiga untuk menyusun runbook mitigasi risiko. Untuk panduan preskriptif mengenai cara merespons dan memitigasi potensi dampak insiden keamanan, lihat [Respons insiden](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html).
1. **Verifikasi bahwa pengaturan memiliki panduan preskriptif atau otomatis.** ID eksternal bukan sesuatu yang rahasia, tetapi ID eksternal tidak boleh berupa nilai yang mudah ditebak, seperti nomor telepon, nama, atau ID akun. Buatlah ID eksternal menjadi bidang hanya baca sehingga ID eksternal tersebut tidak dapat diubah untuk tujuan meniru penyiapan.
Anda atau pihak ketiga dapat membuat ID eksternal. Bentuklah sebuah proses untuk menentukan siapa yang bertanggung jawab dalam pembuatan ID. Siapa pun entitas pembuat ID eksternalnya, pihak ketiga menjaga keunikan dan formatnya tetap konsisten untuk semua pelanggan.
Kebijakan yang dibuat untuk akses lintas akun di akun Anda harus mengikuti [prinsip hak akses paling rendah](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). Pihak ketiga harus menyediakan sebuah dokumen kebijakan peran atau mekanisme penyiapan otomatis yang menggunakan templat AWS CloudFormation atau yang setara. Hal ini akan mengurangi adanya potensi kesalahan yang bisa terjadi pada pembuatan kebijakan manual dan menyediakan jejak yang dapat diaudit. Untuk informasi selengkapnya tentang cara menggunakan templat AWS CloudFormation untuk membuat peran lintas akun, lihat [Peran Lintas Akun](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/).
Pihak ketiga harus menyediakan sebuah mekanisme penyiapan otomatis yang dapat diaudit. Namun, dengan dokumen kebijakan peran yang menguraikan akses yang diperlukan, Anda harus mengotomatiskan penyiapan peran tersebut. Anda harus melakukan pemantauan terhadap perubahan dengan deteksi penyimpangan menggunakan templat AWS CloudFormation atau yang setara sebagai bagian dari praktik audit.
1. **Akun untuk perubahan.** Struktur akun Anda, kebutuhan Anda terhadap pihak ketiga, atau penawaran layanan yang disediakan dapat berubah. Anda harus mengantisipasi perubahan dan kegagalan, dan membuat rencana yang sesuai dengan orang, proses, dan teknologi yang tepat. Lakukan audit tingkat akses yang Anda berikan secara berkala, dan terapkan metode deteksi yang akan memberikan Anda peringatan tentang perubahan yang tidak terduga. Pantau dan audit penggunaan peran dan penyimpanan data ID eksternal. Anda harus bersiap untuk mencabut akses pihak ketiga, baik untuk sementara atau secara permanen, jika terjadi perubahan atau pola akses yang tidak terduga. Selain itu, ukur dampak atas operasi pencabutan Anda, termasuk waktu yang diperlukan untuk melakukannya, orang yang terlibat, biaya, dan dampaknya terhadap sumber daya lainnya.
Untuk panduan preskriptif mengenai metode deteksi, silakan lihat [Praktik terbaik deteksi](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html).
## Sumber daya
**Praktik-praktik terbaik terkait:**
+ [SEC02-BP02 Menggunakan kredensial sementara](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC03-BP05 Tentukan pagar pembatas izin untuk organisasi Anda](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_define_guardrails.html)
+ [SEC03-BP06 Mengelola akses berdasarkan siklus hidup](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
+ [SEC03-BP07 Menganalisis akses publik dan lintas akun](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC04 Deteksi](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Dokumen terkait:**
+ [Pemilik bucket yang memberikan izin lintas akun untuk objek yang bukan miliknya](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [Cara menggunakan kebijakan kepercayaan dengan peran IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Mendelegasikan akses di seluruh Akun AWS menggunakan peran IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [Bagaimana cara mengakses sumber daya di Akun AWS lain dengan menggunakan IAM?](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [Praktik terbaik keamanan di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Logika evaluasi kebijakan lintas akun](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [Cara menggunakan ID eksternal saat memberikan akses ke sumber daya AWS Anda bagi pihak ketiga](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Mengumpulkan Informasi dari Sumber Daya AWS CloudFormation yang Dibuat di Akun Eksternal dengan Sumber Daya Kustom](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [Menggunakan ID Eksternal dengan Aman untuk Mengakses Akun AWS yang Dimiliki oleh Orang Lain](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Memperluas peran IAM ke beban kerja di luar IAM dengan IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)
**Video terkait:**
+ [Bagaimana cara mengizinkan pengguna atau peran yang ada dalam akses Akun AWS terpisah ke Akun AWS saya?](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Menjadi Master Kebijakan IAM dalam 60 Menit atau Kurang](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [Pusat Pengetahuan AWS Langsung: Praktik Terbaik dan Keputusan Desain IAM](https://www.youtube.com/watch?v=xzDFPIQy4Ks)
**Contoh terkait:**
+ [Mengonfigurasikan akses lintas akun ke Amazon DynamoDB](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [Alat Kueri Jaringan AWS STS](https://github.com/aws-samples/aws-sts-network-query-tool)