Menggunakan AWS Organizations untuk keamanan - AWS Panduan Preskriptif

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

Menggunakan AWS Organizations untuk keamanan

Mempengaruhi masa depan AWS Security Reference Architecture (AWS SRA) dengan mengambil survei singkat.

AWS Organizations membantu Anda mengelola dan mengatur lingkungan secara terpusat saat Anda menumbuhkan dan menskalakan sumber daya AWS Anda. Dengan menggunakan AWS Organizations, Anda dapat membuat akun AWS baru secara terprogram, mengalokasikan sumber daya, mengelompokkan akun untuk mengatur beban kerja Anda, dan menerapkan kebijakan ke akun atau grup akun untuk tata kelola. Organisasi AWS mengkonsolidasikan akun AWS Anda sehingga Anda dapat mengelolanya sebagai satu unit. Ini memiliki satu akun manajemen bersama dengan nol atau lebih akun anggota. Sebagian besar beban kerja Anda berada di akun anggota, kecuali untuk beberapa proses yang dikelola secara terpusat yang harus berada di akun manajemen atau di akun yang ditetapkan sebagai administrator yang didelegasikan untuk layanan AWS tertentu. Anda dapat menyediakan alat dan akses dari lokasi pusat bagi tim keamanan Anda untuk mengelola kebutuhan keamanan atas nama organisasi AWS. Anda dapat mengurangi duplikasi sumber daya dengan membagikan sumber daya penting dalam organisasi AWS Anda. Anda dapat mengelompokkan akun ke dalam unit organisasi AWS (OUs), yang dapat mewakili lingkungan yang berbeda berdasarkan persyaratan dan tujuan beban kerja. AWS Organizations juga menyediakan beberapa kebijakan yang memungkinkan Anda menerapkan kontrol keamanan tambahan secara terpusat ke semua akun anggota di organisasi Anda. Bagian ini berfokus pada kebijakan kontrol layanan (SCPs), kebijakan kontrol sumber daya (RCPs), dan kebijakan deklaratif.

Dengan AWS Organizations, Anda dapat menggunakan SCPsdan RCPsmenerapkan pagar pembatas izin di organisasi AWS, OU, atau tingkat akun. SCPs adalah pagar pembatas yang berlaku untuk kepala sekolah dalam akun organisasi, dengan pengecualian akun manajemen (yang merupakan salah satu alasan untuk tidak menjalankan beban kerja di akun ini). Ketika Anda melampirkan SCP ke OU, SCP diwarisi oleh anak OUs dan akun di bawah OU tersebut. SCPs tidak memberikan izin apa pun. Sebagai gantinya, mereka menentukan izin maksimum untuk organisasi AWS, OU, atau akun. Anda masih perlu melampirkan kebijakan berbasis identitas atau berbasis sumber daya ke prinsipal atau sumber daya di akun AWS Anda untuk benar-benar memberikan izin kepada mereka. Misalnya, jika SCP menolak akses ke semua Amazon S3, prinsipal yang terpengaruh oleh SCP tidak akan memiliki akses ke Amazon S3 bahkan jika mereka secara eksplisit diberikan akses melalui kebijakan IAM. Untuk informasi lebih lanjut tentang bagaimana kebijakan IAM dievaluasi, peran SCPs, dan bagaimana akses akhirnya diberikan atau ditolak, lihat logika evaluasi kebijakan dalam dokumentasi IAM.

RCPs adalah pagar pembatas yang berlaku untuk sumber daya dalam akun organisasi, terlepas dari apakah sumber daya milik organisasi yang sama. Seperti SCPs, RCPs jangan memengaruhi sumber daya di akun manajemen dan jangan berikan izin apa pun. Ketika Anda melampirkan RCP ke OU, RCP diwarisi oleh anak OUs dan akun di bawah OU. RCPs memberikan kontrol pusat atas izin maksimum yang tersedia untuk sumber daya di organisasi Anda dan saat ini mendukung subset layanan AWS. Saat Anda mendesain SCPs untuk Anda OUs, kami sarankan Anda mengevaluasi perubahan dengan menggunakan simulator kebijakan IAM. Anda juga harus meninjau data layanan yang terakhir diakses di IAM dan menggunakan AWS CloudTrail untuk mencatat penggunaan layanan di tingkat API untuk memahami potensi dampak perubahan SCP.

SCPs dan RCPs merupakan kontrol independen. Anda dapat memilih untuk mengaktifkan saja SCPs atau RCPs, atau menggunakan kedua jenis kebijakan bersama-sama berdasarkan kontrol akses yang ingin Anda terapkan. Misalnya, jika Anda ingin mencegah prinsipal organisasi mengakses sumber daya di luar organisasi, Anda menerapkan kontrol ini dengan menggunakan. SCPs Jika Anda ingin membatasi atau mencegah identitas eksternal mengakses sumber daya Anda, Anda menerapkan kontrol ini dengan menggunakan. RCPs Untuk informasi selengkapnya dan kasus penggunaan untuk RCPs dan SCPs, lihat Menggunakan SCPs dan RCPs dalam dokumentasi AWS Organizations.

Anda dapat menggunakan kebijakan deklaratif AWS Organizations untuk mendeklarasikan dan menerapkan konfigurasi yang Anda inginkan secara terpusat untuk layanan AWS tertentu dalam skala besar di seluruh organisasi. Misalnya, Anda dapat memblokir akses internet publik ke sumber daya Amazon VPC di seluruh organisasi Anda. Tidak seperti kebijakan otorisasi seperti SCPs dan RCPs, kebijakan deklaratif diberlakukan di bidang kontrol layanan AWS. Kebijakan otorisasi mengatur akses ke APIs, sedangkan kebijakan deklaratif diterapkan langsung di tingkat layanan untuk menegakkan maksud tahan lama. Kebijakan ini membantu memastikan bahwa konfigurasi dasar untuk layanan AWS selalu dipertahankan, bahkan ketika layanan memperkenalkan fitur baru atau. APIs Konfigurasi dasar juga dipertahankan ketika akun baru ditambahkan ke organisasi atau ketika prinsip dan sumber daya baru dibuat. Kebijakan deklaratif dapat diterapkan ke seluruh organisasi atau untuk spesifik OUs atau akun.

Setiap akun AWS memiliki satu pengguna root yang memiliki izin penuh ke semua sumber daya AWS secara default.  Sebagai praktik keamanan terbaik, kami menyarankan Anda untuk tidak menggunakan pengguna root kecuali untuk beberapa tugas yang secara eksplisit memerlukan pengguna root. Jika Anda mengelola beberapa akun AWS melalui AWS Organizations, Anda dapat menonaktifkan proses masuk root secara terpusat dan kemudian melakukan tindakan hak istimewa root atas nama semua akun anggota. Setelah Anda mengelola akses root untuk akun anggota secara terpusat, Anda dapat menghapus kata sandi pengguna root, kunci akses, dan menandatangani sertifikat, dan menonaktifkan otentikasi multi-faktor (MFA) untuk akun anggota. Akun baru yang dibuat di bawah akses root yang dikelola secara terpusat tidak memiliki kredenal pengguna root secara default. Akun anggota tidak dapat masuk dengan pengguna root mereka atau melakukan pemulihan kata sandi untuk pengguna root mereka.

AWS Control Tower menawarkan cara sederhana untuk mengatur dan mengatur beberapa akun. Ini mengotomatiskan penyiapan akun di organisasi AWS Anda, mengotomatiskan penyediaan, menerapkan pagar pembatas (yang mencakup kontrol preventif dan detektif), dan memberi Anda dasbor untuk visibilitas. Kebijakan manajemen IAM tambahan, batas izin, dilampirkan ke entitas IAM tertentu (pengguna atau peran) dan menetapkan izin maksimum yang dapat diberikan oleh kebijakan berbasis identitas kepada entitas IAM.

AWS Organizations membantu Anda mengonfigurasi layanan AWS yang berlaku untuk semua akun Anda. Misalnya, Anda dapat mengonfigurasi pencatatan pusat dari semua tindakan yang dilakukan di seluruh organisasi AWS Anda dengan menggunakan AWS CloudTrail, dan mencegah akun anggota menonaktifkan pencatatan. Anda juga dapat menggabungkan data secara terpusat untuk aturan yang telah Anda tetapkan dengan menggunakan AWS Config, sehingga Anda dapat mengaudit beban kerja Anda untuk kepatuhan dan bereaksi cepat terhadap perubahan. Anda dapat menggunakan AWS CloudFormation StackSets untuk mengelola CloudFormation tumpukan AWS secara terpusat di seluruh akun dan OUs di organisasi AWS Anda, sehingga Anda dapat secara otomatis menyediakan akun baru untuk memenuhi persyaratan keamanan Anda.

Konfigurasi default AWS Organizations mendukung penggunaan SCPs sebagai daftar penolakan. Dengan menggunakan strategi daftar tolak, administrator akun anggota dapat mendelegasikan semua layanan dan tindakan sampai Anda membuat dan melampirkan SCP yang menolak layanan atau serangkaian tindakan tertentu. Pernyataan penolakan memerlukan pemeliharaan yang lebih sedikit daripada daftar izin, karena Anda tidak perlu memperbaruinya saat AWS menambahkan layanan baru. Pernyataan penolakan biasanya lebih pendek dalam panjang karakter, jadi lebih mudah untuk tetap dalam ukuran maksimum untuk SCPs. Dalam pernyataan di mana Effect elemen memiliki nilaiDeny, Anda juga dapat membatasi akses ke sumber daya tertentu, atau menentukan kondisi kapan SCPs berlaku. Sebaliknya, pernyataan Izinkan dalam SCP berlaku untuk semua sumber daya ("*") dan tidak dapat dibatasi oleh kondisi. Untuk informasi dan contoh selengkapnya, lihat Strategi untuk digunakan SCPs dalam dokumentasi AWS Organizations.

Pertimbangan desain

  • Atau, untuk digunakan SCPs sebagai daftar izin, Anda harus mengganti FullAWSAccess SCP yang dikelola AWS dengan SCP yang secara eksplisit hanya mengizinkan layanan dan tindakan yang ingin Anda izinkan. Agar izin diaktifkan untuk akun tertentu, setiap SCP (dari root melalui setiap OU di jalur langsung ke akun dan bahkan dilampirkan ke akun itu sendiri) harus mengizinkan izin itu. Model ini bersifat lebih ketat dan mungkin cocok untuk beban kerja yang sangat diatur dan sensitif. Pendekatan ini mengharuskan Anda untuk secara eksplisit mengizinkan setiap layanan atau tindakan IAM di jalur dari akun AWS ke OU.

  • Idealnya, Anda akan menggunakan kombinasi daftar tolak dan mengizinkan strategi daftar. Gunakan daftar izinkan untuk menentukan daftar layanan AWS yang diizinkan yang disetujui untuk digunakan dalam organisasi AWS dan lampirkan SCP ini di root organisasi AWS Anda. Jika Anda memiliki serangkaian layanan berbeda yang diizinkan per lingkungan pengembangan Anda, Anda akan melampirkan masing-masing SCPs di setiap OU. Anda kemudian dapat menggunakan daftar penolakan untuk menentukan pagar pembatas perusahaan dengan secara eksplisit menolak tindakan IAM tertentu.

  • RCPs berlaku untuk sumber daya untuk subset layanan AWS. Untuk informasi selengkapnya, lihat Daftar layanan AWS yang mendukung RCPs dalam dokumentasi AWS Organizations. Konfigurasi default AWS Organizations mendukung penggunaan daftar penolakan RCPs sebagai. Saat Anda mengaktifkan RCPs di organisasi Anda, kebijakan terkelola AWS yang RCPFullAWSAccess disebut secara otomatis dilampirkan ke root organisasi, setiap OU, dan setiap akun di organisasi Anda. Anda tidak dapat melepaskan kebijakan ini. RCP default ini memungkinkan semua prinsipal dan tindakan akses untuk melewati evaluasi RCP. Ini berarti bahwa sampai Anda mulai membuat dan melampirkan RCPs, semua izin IAM Anda yang ada terus beroperasi seperti yang mereka lakukan. Kebijakan terkelola AWS ini tidak memberikan akses. Anda kemudian dapat membuat yang baru RCPs sebagai daftar pernyataan penolakan untuk memblokir akses ke sumber daya di organisasi Anda.