Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Kontrol standar di AMS Advanced
Berikut ini adalah kontrol standar di AMS:
Berikut ini adalah kontrol standar untuk 001 - Tagging Configuration.
Semua AWS sumber daya yang dibutuhkan oleh tim AMS untuk tujuan operasional dan manajemen harus memiliki pasangan nilai kunci berikut.
AppId= AMSInfrastructure
Lingkungan= AMSInfrastructure
AppName = AMSInfrastructure
AMSResource=Benar
Semua tag yang diperlukan oleh tim AMS selain yang tercantum sebelumnya harus memiliki awalan seperti yang disebutkan dalam daftar awalan AMS (lihat Catatan).
Nilai tag yang diperlukan oleh tim AMS (AppId, Lingkungan, dan AppName) dapat diubah pada salah satu sumber daya yang dibuat oleh Anda berdasarkan permintaan perubahan Anda.
Tag apa pun pada tumpukan yang diperlukan oleh AMS tidak boleh dihapus berdasarkan permintaan perubahan Anda.
Anda tidak dapat menggunakan konvensi penamaan tag AMS untuk infrastruktur Anda, seperti yang disebutkan di poin 2.
Anda dapat membuat tag kustom di sumber daya yang diperlukan oleh AMS (biasanya untuk kasus penggunaan penagihan dan pelaporan biaya). Tag kustom dipertahankan jika sumber daya diperbarui oleh pembaruan tumpukan dan bukan dengan memperbarui template.
catatan
Daftar Awalan AMS
ams-*
AWSManagedLayanan*
/ams/ *
am*
AM*
Ams*
mc*
MC*
Mc*
sentinel*
Sentinel*
Managed_Services*
NEWAMS*
AWS_*
aw*
VPC_*
CloudTrail*
Cloudtrail*
/aws_reserved/
MENELAN*
EPSDB*
MMS*
TemplateId*
StackSet-am*
StackSet-AWS-Zona Pendaratan
IAMPolicy*
pelanggan-mc-*
Akar*
LandingZone*
StateMachine*
codedeploy_service_role
managementhost
sentinel.int.
eps
UnhealthyInServiceBastion
ms-
| ID | Standar teknis |
|---|---|
| 1.0 | Durasi Batas Waktu |
| 1.1 | Sesi batas waktu default pengguna federasi adalah satu jam dan dapat ditingkatkan hingga empat jam. |
| 1.2 | Waktu Akses Stack Default adalah 12 jam. |
| 2.0 | AWS Penggunaan Akun Root |
| 2.1 | Jika ada penggunaan akun root karena alasan apa pun, Amazon GuardDuty harus dikonfigurasi untuk menghasilkan temuan yang relevan. |
| 2.2 | Untuk akun single-account landing zone (SALZ) dan akun manajemen multi-account landing zone (MALZ) (sebelumnya dikenal sebagai Master/Billing akun), akun pengguna Root harus mengaktifkan MFA virtual dan token lunak MFA dibuang selama akun on-boarding, sehingga AMS maupun pelanggan tidak dapat masuk sebagai root. Proses kehilangan kata sandi AWS root standar harus diikuti bersama dengan AMS Cloud Service Delivery Manager (CSDM) Anda. Konfigurasi ini harus tetap ada selama siklus hidup akun terkelola AMS. |
| 2.3 | Anda tidak boleh membuat kunci akses untuk akun root. |
| 3.0 | Pembuatan dan Modifikasi Pengguna |
| 3.1 | IAM users/roles dengan akses terprogram dan dengan izin baca saja dapat dibuat tanpa kebijakan terbatas waktu. Namun, izin untuk mengizinkan pembacaan objek (misalnya, S3:GetObject) di semua bucket Amazon Simple Storage Service di akun tidak diizinkan. |
| 3.1.1 | Pengguna manusia IAM untuk akses konsol dan dengan izin baca saja dapat dibuat dengan kebijakan terikat waktu (hingga 180 hari) sedangkan kebijakan terikat waktu akan menghasilkan pemberitahuan risiko. removal/renewal/extension Namun, izin untuk mengizinkan pembacaan objek (misalnya, S3:GetObject) di semua ember S3 di akun tidak diizinkan. |
| 3.2 | Pengguna IAM dan peran untuk konsol dan akses terprogram dengan izin mutasi infrastruktur apa pun (manajemen tulis dan izin) di akun pelanggan tidak boleh dibuat tanpa penerimaan risiko. Ada pengecualian untuk izin tulis tingkat objek S3 yang diizinkan tanpa penerimaan risiko selama bucket tertentu berada dalam cakupan dan operasi penandaan pada tag terkait non-AMS. |
| 3.3 | Pengguna IAM dengan akses terprogram, diberi nama customer_servicenow_user dan customer_servicenow_logging_user diperlukan untuk ServiceNow integrasi dalam akun aplikasi SALZ atau MALZ dan *akun inti* dapat dibuat tanpa kebijakan terbatas waktu. |
| 3.4 | Pengguna IAM dengan akses terprogram, menggunakan customer_cloud_endure_policy dan customer_cloud_endure_deny_policy (dengan akses hanya-baca) yang diperlukan untuk CloudEndure integrasi dalam akun SALZ dan MALZ dapat dibuat tetapi memerlukan kebijakan terbatas waktu untuk periode migrasi yang direncanakan. Batas waktu bisa untuk jangka waktu maksimum 180 hari tanpa RA. SCP juga berwenang untuk perubahan akun MALZ agar kebijakan ini berfungsi selama periode yang diperlukan. Anda menentukan jendela migrasi yang sesuai untuk kebutuhan Anda dan menyesuaikan sesuai kebutuhan. |
| 4.0 | Kebijakan, Tindakan, dan APIs |
| 4.1 | Semua pengguna dan peran IAM Anda di akun SALZ harus memiliki Kebijakan Penolakan Pelanggan (CDP) default yang dilampirkan untuk melindungi infrastruktur AMS dari kerusakan yang tidak disengaja atau disengaja. |
| 4.2 | AMS SCPs harus diaktifkan di semua akun terkelola AMS di MALZ. |
| 4.3 | Identitas yang mampu melakukan tindakan administratif pada kunci KMS, seperti, dan PutKeyPolicyScheduleKeyDeletion, harus dibatasi hanya untuk operator AMS dan prinsip otomatisasi. |
| 4.4 | Kebijakan tidak boleh memberikan akses administrator dengan pernyataan yang setara dengan “Efek”: “Izinkan” dengan “Tindakan”: “*” di atas “Sumber Daya”: “*” tanpa penerimaan risiko. |
| 4,5 | Kebijakan IAM tidak boleh menyertakan tindakan apa pun yang mencakup tindakan Izinkan S3: *** pada bucket apa pun tanpa penerimaan risiko. |
| 4.6 | Panggilan API terhadap kebijakan kunci KMS untuk kunci infrastruktur AMS dalam kebijakan IAM pelanggan tidak boleh diizinkan. |
| 4.7 | Tindakan yang melewati proses manajemen perubahan (RFC) tidak boleh diizinkan, seperti memulai atau menghentikan instance, pembuatan bucket S3 atau instance RDS, dan sebagainya. |
| 4.8 | Tindakan yang membuat perubahan pada catatan DNS infrastruktur AMS di Amazon Route 53 tidak boleh diizinkan. |
| 4.9 | Pengguna manusia IAM dengan akses konsol yang dibuat setelah mengikuti proses hukum, tidak boleh memiliki kebijakan apa pun yang dilampirkan secara langsung kecuali kebijakan kepercayaan, peran, dan kebijakan terbatas waktu. |
| 4.10 | Profil EC2 instans Amazon dengan akses baca ke rahasia atau namespace tertentu di AWS Secrets Manager dalam akun yang sama dapat dibuat. |
| 4.11 | Izin AWS Managed Services Change Management (AMSCM) atau AWS Managed Services Service Knowledge Management System (AMSSKMS) dapat ditambahkan ke peran apa pun (kemampuan untuk membuka). SR/Incident/RFC |
| 4.12 | Kebijakan IAM tidak boleh menyertakan tindakan apa pun yang mencakup tindakan Izinkan log: DeleteLogGroup dan log: DeleteLogStream pada grup CloudWatch log AMS Amazon mana pun. |
| 4.13 | Izin untuk membuat kunci Multi-wilayah tidak boleh diizinkan. |
| 4.14 | Untuk menyediakan akses ke bucket S3 ARNs yang belum dibuat di akun Anda, gunakan kunci kondisi S3 khusus layanan s3:ResourceAccount untuk menentukan nomor akun. |
| 4.15 | Anda dapat melihat, membuat, membuat daftar, dan menghapus akses ke dasbor khusus Anda, tetapi hanya melihat dan mencantumkan akses di CloudWatch dasbor Amazon. |
| 4.15.1 | Anda dapat melihat, membuat, membuat daftar, dan menghapus akses ke dasbor kustom lensa penyimpanan S3 Anda. |
| 4.16 | Izin penuh terkait SQL Workbench dapat diberikan roles/users untuk bekerja di database Amazon Redshift. |
| 4.17 | AWS CloudShell Izin apa pun dapat diberikan kepada peran pelanggan sebagai alternatif CLI. |
| 4.18 | Peran IAM dengan Layanan AWS sebagai prinsipal tepercaya juga harus sesuai dengan standar teknis IAM. |
| 4.19 | Peran Tertaut Layanan (SLRs) tidak tunduk pada standar teknis AMS IAM, karena dibuat dan dikelola oleh Tim Layanan IAM. |
| 4.20 | Kebijakan IAM tidak boleh mengizinkan akses baca tak terbatas ke objek bucket Amazon S3 (misalnya, Amazon S3GetObject:) di semua bucket dalam akun:
|
| 4.21 | Semua izin IAM untuk jenis sumber daya “savingsplan” dapat diberikan kepada pelanggan. |
| 4.22 | Insinyur AMS tidak diizinkan untuk menyalin atau memindahkan data pelanggan (file, objek S3, database) secara manual di salah satu layanan penyimpanan data, seperti Amazon S3, Amazon Relational Database Service, Amazon DynamoDB, dan sebagainya, atau dalam sistem file OS. |
| 4.23 | Kebijakan SCP tidak boleh dimodifikasi untuk mengizinkan akses tambahan apa pun di salah satu akun yang dikelola AMS. |
| 4.24 | Setiap perubahan dalam kebijakan SCP yang mungkin merusak infrastruktur AMS atau kemampuan manajemen tidak boleh diizinkan. (Catatan: Sumber daya AMS memiliki tag AppId= AMSInfrastructure dan mengikuti AMS Protected Namespace). |
| 4.25 | Fitur Penyediaan IAM Otomatis AMS harus diaktifkan di akun Anda sebagai fitur keikutsertaan. |
| 4.26 | Peran atau pengguna yang diasumsikan manusia AMS tidak boleh memiliki akses ke konten pelanggan di S3, RDS, DynamoDB, Redshift, Elasticache, EFS, dan. FSx Selain itu, akses apa pun ke yang diketahui dan baru APIs dirilis oleh pihak lain Layanan AWS yang memberikan akses ke konten pelanggan harus ditolak secara eksplisit dalam peran operator. |
| 5.0 | Federasi |
| 5.1 | Otentikasi harus dikonfigurasi menggunakan federasi di akun terkelola AMS. |
| 5.2 | Harus ada kepercayaan keluar satu arah dari AMS AD ke direktori aktif Anda (AMS AD mempercayai AD di prem). |
| 5.3 | Penyimpanan identitas Anda yang digunakan untuk mengautentikasi ke AMS tidak boleh ada di akun aplikasi terkelola AMS. |
| 6.0 | Kebijakan Lintas Akun |
| 6.1 | Kebijakan kepercayaan peran IAM antara akun AMS yang dimiliki oleh pelanggan yang sama sesuai catatan pelanggan, dapat dikonfigurasi. |
| 6.2 | Kebijakan kepercayaan peran IAM antara akun AMS dan non-AMS harus dikonfigurasi hanya jika akun non-AMS dimiliki oleh pelanggan AMS yang sama (dengan mengonfirmasi bahwa akun tersebut berada di bawah AWS Organizations akun yang sama atau dengan mencocokkan domain email dengan nama perusahaan pelanggan). |
| 6.3 | Kebijakan kepercayaan peran IAM antara akun AMS dan akun pihak ketiga tidak boleh dikonfigurasi tanpa penerimaan risiko. |
| 6.4 | Kebijakan lintas akun untuk mengakses semua yang dikelola pelanggan CMKs antara akun AMS dari pelanggan yang sama dapat dikonfigurasi. |
| 6.5 | Kebijakan lintas akun untuk mengakses kunci KMS apa pun dalam akun non-AMS oleh akun AMS dapat dikonfigurasi. |
| 6.6 | Kebijakan lintas akun untuk mengakses kunci KMS apa pun dalam akun AMS oleh akun pihak ketiga tidak boleh diizinkan tanpa penerimaan risiko. |
| 6.6.1 | Kebijakan lintas akun untuk mengakses kunci KMS apa pun dalam akun AMS oleh akun non-AMS hanya dapat dikonfigurasi jika akun non-AMS dimiliki oleh pelanggan AMS yang sama. |
| 6.7 | Kebijakan lintas akun untuk mengakses data bucket S3 atau sumber daya tempat data dapat disimpan (seperti Amazon RDS, Amazon DynamoDB, atau Amazon Redshift) antara akun AMS dari pelanggan yang sama dapat dikonfigurasi. |
| 6.8 | Kebijakan lintas akun untuk mengakses data bucket S3 atau sumber daya tempat data dapat disimpan (seperti Amazon RDS, Amazon DynamoDB, atau Amazon Redshift) di akun non-AMS dari akun AMS dengan akses hanya-baca dapat dikonfigurasi. |
| 6.9 | Kebijakan lintas akun untuk mengakses data bucket S3 atau sumber daya di mana data dapat disimpan (seperti Amazon RDS, Amazon DynamoDB, atau Amazon Redshift) dengan izin menulis dari AMS ke akun non-AMS (atau akun non-AMS ke AMS) harus dikonfigurasi hanya jika akun non-AMS dimiliki oleh pelanggan AMS yang sama (dengan mengonfirmasi bahwa mereka berada di bawah AWS Organizations akun yang sama atau dengan mencocokkan email domain dengan nama perusahaan pelanggan). |
| 6.10 | Kebijakan lintas akun untuk mengakses data bucket S3 atau sumber daya tempat data dapat disimpan (seperti Amazon RDS, Amazon DynamoDB, atau Amazon Redshift) di akun pihak ketiga dari akun AMS dengan akses hanya baca dapat dikonfigurasi. |
| 6.11 | Kebijakan lintas akun untuk mengakses data bucket S3 atau sumber daya tempat data dapat disimpan (seperti Amazon RDS, Amazon DynamoDB, atau Amazon Redshift) di akun pihak ketiga dari akun AMS dengan akses tulis tidak boleh dikonfigurasi. |
| 6.12 | Kebijakan lintas akun dari akun pihak ketiga untuk mengakses bucket S3 pelanggan AMS atau sumber daya tempat data dapat disimpan (seperti Amazon RDS, Amazon DynamoDB, atau Amazon Redshift) tidak boleh dikonfigurasi tanpa penerimaan risiko. |
| 7.0 | Grup Pengguna |
| 7.1 | Grup IAM dengan izin readonly dan non mutatif diizinkan. |
| 8.0 | Kebijakan berbasis sumber daya |
| 8.1 | Sumber daya infrastruktur AMS harus dilindungi dari manajemen oleh identitas yang tidak sah dengan lampiran kebijakan berbasis sumber daya. |
| 8.2 | Sumber daya Anda harus dikonfigurasi dengan kebijakan berbasis sumber daya dengan hak istimewa terkecil, kecuali Anda secara eksplisit menentukan kebijakan yang berbeda. |
| 9.0 | Layanan penyediaan layanan mandiri (SSPS) |
| 9.1 | Peran atau kebijakan IAM default AMS (termasuk profil instans, SSPS, pola) tidak boleh dimodifikasi dengan atau tanpa penerimaan risiko apa pun. Pengecualian diperbolehkan (tanpa penerimaan risiko) untuk kebijakan kepercayaan. Penandaan peran, kebijakan, atau perubahan pengguna, juga diizinkan dalam peran SSP default. |
| 9.3 | Kebijakan SSPS untuk peran konsol Systems Manager Automation tidak dapat dilampirkan ke peran kustom apa pun selain dari peran default. Kebijakan SSPS lainnya hanya boleh dilampirkan ke peran IAM kustom setelah memastikan lampiran kebijakan ke peran kustom tidak memberikan izin tambahan di luar desain yang dimaksudkan untuk layanan SSPS default. |
Berikut ini adalah kontrol standar untuk 003 - Keamanan Jaringan:
| ID | Standar teknis |
|---|---|
| Jaringan | |
| 1.0 | Semua EC2 instance harus diakses melalui SSH atau RDP hanya melalui host Bastion, rentang VPC CIDR host bastion atau dari rentang VPC CIDR instance yang sama. |
| 2.0 | IP elastis pada EC2 instans diizinkan |
| 3.0 | Bidang kontrol AMS dan dengan ekstensi di bidang data TLS 1.2+ harus digunakan. |
| 4.0 | Semua lalu lintas keluar harus lewat menggunakan akun IGW atau TGW. |
| 5.0 | Grup keamanan tidak boleh memiliki sumber sebagai 0.0.0.0/0 dalam aturan masuk jika tidak dilampirkan ke penyeimbang beban sesuai 9.0 |
| 6.0 | Bucket atau objek S3 tidak boleh dipublikasikan tanpa penerimaan risiko. |
| 7.0 | Akses manajemen server pada port SSH/22 atau SSH/2222 (Bukan SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/5900-5901 TS/CITRIX/1494 atau 1604, LDAP/389 atau 636 dan RPC/135, NETBIOS/137-139 tidak boleh diizinkan dari luar VPC melalui kelompok keamanan. |
| 8.0 | Akses manajemen basis data pada port (MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) atau pada port khusus tidak boleh diizinkan dari publik yang tidak dirutekan ke VPC melalui DX, VPC-peer, atau VPN melalui grup keamanan. IPs |
| 8.1 | Sumber daya apa pun di mana data pelanggan dapat disimpan tidak boleh diekspos ke internet publik secara langsung. |
| 9.0 | Akses aplikasi langsung melalui port HTTP/80, HTTPS/8443 dan HTTPS/443 dari Internet hanya diizinkan untuk memuat penyeimbang, tetapi tidak untuk sumber daya komputasi apa pun secara langsung, misalnya, instance, kontainer, dll. EC2 ECS/EKS/Fargate |
| 10.0 | Akses aplikasi melalui port HTTP/80 dan HTTPS/443 dari rentang IP pribadi pelanggan dapat diizinkan. |
| 11.0 | Setiap perubahan pada grup keamanan yang mengontrol akses ke infrastruktur AMS tidak boleh diizinkan tanpa penerimaan risiko. |
| 12.0 | AMS Security mengacu pada standar setiap kali grup keamanan diminta untuk dilampirkan ke sebuah instans. |
| 13,0 | Akses benteng pelanggan pada port 3389 dan 22 harus diizinkan hanya dari rentang IP Pribadi yang dialihkan ke VPC melalui DX, VPC-peer, atau VPN. |
| 14.0 | Asosiasi lintas akun zona yang dihosting pribadi dengan VPCs dari AMS ke akun non-AMS (atau akun non-AMS ke AMS) harus dikonfigurasi hanya jika akun non-AMS dimiliki oleh pelanggan AMS yang sama (dengan mengonfirmasi bahwa akun tersebut berada di bawah akun AWS Organization yang sama atau dengan mencocokkan domain email dengan nama perusahaan pelanggan) menggunakan alat internal. |
| 15.0 | Koneksi peering VPC antar akun milik pelanggan yang sama dapat diizinkan. |
| 16.0 | Basis AMS AMIs dapat dibagikan dengan akun non-AMS selama kedua akun dimiliki oleh pelanggan yang sama (dengan mengonfirmasi bahwa mereka berada di bawah AWS Organizations akun yang sama atau dengan mencocokkan domain email dengan nama perusahaan pelanggan) menggunakan alat internal. |
| 17.0 | Port FTP 21 tidak boleh dikonfigurasi di salah satu grup keamanan tanpa penerimaan risiko. |
| 18.0 | Konektivitas jaringan lintas akun melalui gateway transit diizinkan selama semua akun dimiliki oleh pelanggan. |
| 19.0 | Membuat subnet pribadi ke publik tidak diizinkan |
| 20.0 | Koneksi peering VPC dengan akun pihak ketiga (tidak dimiliki oleh pelanggan) tidak boleh diizinkan. |
| 21.0 | Lampiran Transit Gateway dengan akun pihak ketiga (tidak dimiliki oleh pelanggan) tidak boleh diizinkan. |
| 22.0 | Setiap lalu lintas jaringan yang diperlukan untuk AMS untuk menyediakan layanan kepada pelanggan tidak boleh diblokir di titik keluar jaringan pelanggan. |
| 23,0 | Berbagi aturan resolver dengan Akun AWS dimiliki oleh pelanggan yang sama diperbolehkan dengan pemberitahuan risiko |
| 19.0 | ICMP |
| 19.1 | Permintaan ICMP masuk ke Amazon EC2 dari infra pelanggan akan memerlukan pemberitahuan risiko. |
| 19.2 | Permintaan masuk dari publik yang IPs dialihkan ke Amazon VPC melalui DX, VPC-peer, atau VPN melalui grup keamanan diperbolehkan. |
| 19.3 | Permintaan masuk dari publik yang IPs tidak diarahkan ke Amazon VPC melalui DX, VPC-peer, atau VPN melalui grup keamanan akan memerlukan penerimaan risiko. |
| 19.4 | Permintaan ICMP keluar dari Amazon EC2 ke tujuan mana pun diizinkan. |
| 20.0 | Berbagi kelompok keamanan |
| 20.1 | Jika grup keamanan memenuhi standar keamanan ini, maka grup tersebut dapat dibagi antara VPCs di akun yang sama dan antar akun di organisasi yang sama. |
| 20.2 | Jika grup keamanan tidak memenuhi standar ini dan penerimaan risiko sebelumnya diperlukan untuk grup keamanan ini, maka penggunaan fitur berbagi grup keamanan antara VPCs di akun yang sama, atau antar akun di organisasi yang sama, tidak diizinkan tanpa penerimaan risiko untuk VPC atau akun baru itu. |
Berikut ini adalah kontrol standar untuk 004 - Pengujian Penetrasi
AMS tidak mendukung infrastruktur pentest. Ini adalah tanggung jawab pelanggan. Misalnya, Kali bukan distribusi Linux yang didukung AMS.
Pelanggan harus mematuhi Pengujian Penetrasi
. AMS harus diberitahu sebelumnya 24 jam sebelumnya dalam kasus ketika pelanggan ingin melakukan pengujian penetrasi infrastruktur dalam akun.
AMS akan menyediakan infrastruktur pentesting pelanggan sesuai kebutuhan pelanggan yang secara eksplisit dinyatakan dalam permintaan perubahan atau permintaan layanan oleh pelanggan.
Manajemen identitas untuk infrastruktur pentesting pelanggan adalah tanggung jawab pelanggan.
Berikut ini adalah kontrol standar untuk 005 - GuardDuty
GuardDuty harus diaktifkan di semua akun pelanggan setiap saat.
GuardDuty Temuan dari Akun Aplikasi Terkelola Pelanggan (CMA) di MALZ tidak akan menghasilkan alarm untuk tim operasi.
GuardDuty peringatan harus disimpan dalam akun yang sama atau akun terkelola lainnya di bawah organisasi yang sama.
Fitur daftar IP tepercaya tidak GuardDuty boleh digunakan. Sebaliknya pengarsipan otomatis dapat digunakan sebagai alternatif, yang berguna untuk tujuan audit.
GuardDuty delegasi administrator tidak boleh diaktifkan di MALZ karena administrator yang didelegasikan akan dapat melakukan tindakan hak istimewa tinggi seperti menonaktifkan akun lain tanpa penerimaan GuardDuty risiko.
GuardDuty Filter Arsip Otomatis harus menggunakan cakupan minimal untuk pengembalian maksimum. Misalnya, jika AMS akan melihat beberapa yang tidak dapat diprediksi IPs di blok CIDR yang berbeda, dan ada ASN perusahaan yang sesuai untuk digunakan, gunakan ASN. Namun, jika Anda dapat menjangkau rentang tertentu atau alamat /32, maka cakupannya.
Berikut ini adalah kontrol standar untuk 006 - Host Security
Agen anti-virus harus berjalan pada semua EC2 kasus setiap saat. (misalnya, Trend Micro DSM).
Modul anti-malware harus diaktifkan.
Agen EPS harus menyertakan semua direktori dan file untuk pemindaian.
File yang dikarantina oleh solusi anti-virus dapat dibagikan dengan Anda sesuai permintaan.
Solusi keamanan endpoint pihak ketiga tidak boleh diinstal.
Frekuensi pembaruan tanda tangan anti-virus harus diatur setidaknya sekali dalam sehari.
Frekuensi pemindaian terjadwal harus diatur setidaknya sekali dalam sebulan.
Pemindaian real-time (on-access) harus diaktifkan dan dijalankan setiap saat.
AMS tidak boleh menjalankan skrip kustom apa pun yang tidak dimiliki atau ditulis oleh AMS pada instans Anda. (Catatan: Anda dapat melakukannya dengan menggunakan akses Admin tumpukan melalui CT akses Stack Admin atau dengan menggunakan AWS Systems Manager Automation (AMS SSPS).
Network Level Authentication (NLA) tidak boleh dinonaktifkan pada host windows.
Sistem operasi host harus up to date dengan patch keamanan terbaru sesuai siklus patch yang dikonfigurasi.
Akun terkelola AMS tidak boleh memiliki instans yang tidak dikelola di akun.
Pembuatan akun administrator lokal pada instans Anda oleh AMS tidak boleh diizinkan.
Pasangan kunci pada tidak EC2 boleh dibuat.
Anda tidak boleh menggunakan sistem operasi yang dinyatakan sebagai End of Life (EOL) dan tidak ada dukungan keamanan lebih lanjut yang diberikan oleh vendor atau pihak ketiga.
Berikut ini adalah kontrol standar untuk 007 - Logging
| ID | Standar teknis |
|---|---|
| 1.0 | Jenis log |
| 1.1 | Log OS: Semua host harus log pada acara otentikasi host minimum, mengakses peristiwa untuk semua penggunaan hak istimewa yang ditinggikan dan peristiwa akses untuk semua perubahan pada konfigurasi akses dan hak istimewa termasuk keberhasilan dan kegagalan keduanya. |
| 1.2 | AWS CloudTrail: pencatatan peristiwa CloudTrail manajemen harus diaktifkan dan dikonfigurasi untuk mengirimkan log ke bucket S3. |
| 1.3 | VPC Flow Logs: Semua log lalu lintas jaringan harus dicatat melalui VPC Flow Logs. |
| 1.4 | Pencatatan Akses Server Amazon S3: Ember S3 yang diamanatkan AMS yang menyimpan log harus mengaktifkan pencatatan akses server. |
| 1.5 | AWS Config Snapshots: AWS Config harus merekam perubahan konfigurasi untuk semua sumber daya yang didukung di semua wilayah dan mengirimkan file snapshot konfigurasi ke bucket S3 setidaknya sekali per hari. |
| 1.6 | Log Sistem Perlindungan Titik Akhir (EPS): Pencatatan solusi EPS harus diaktifkan dan dikonfigurasi untuk mengirimkan log ke grup CloudWatch log Log. |
| 1.7 | Log Aplikasi: Pelanggan diberdayakan untuk mengaktifkan pencatatan di aplikasi mereka dan menyimpannya di grup CloudWatch log Log atau bucket S3. |
| 1.8 | Pencatatan level objek S3: Pelanggan diberdayakan untuk mengaktifkan pencatatan level objek di bucket S3 mereka. |
| 1.9 | Service Logging: Pelanggan diberdayakan untuk mengaktifkan dan meneruskan log untuk layanan SSPS seperti layanan inti lainnya. |
| 1.10 | Log Elastic Load Balancing (Classic/Application Load Balancer/NetworkLoad Balancer): Entri akses dan log kesalahan harus disimpan di bucket S3 yang dikelola AMS 2.0. |
| 2.0 | Kontrol akses |
| 2.1 | Anda tidak boleh memiliki akses tulis atau hapus di bucket S3 yang diperlukan oleh AMS yang menyimpan log dan log; CloudWatch grup log. |
| 2.2 | Anda harus memiliki akses read-only ke semua log di akun Anda. |
| 2.3 | Bucket S3 yang diamanatkan AMS yang menyimpan log tidak boleh mengizinkan pengguna akun pihak ketiga sebagai prinsip dalam kebijakan bucket. |
| 2.4 | Log dari grup CloudWatch log Log tidak boleh dihapus tanpa persetujuan eksplisit dari kontak keamanan resmi Anda. |
| 3.0 | Retensi log |
| 3.1 | Grup CloudWatch log log yang diamanatkan AMS harus memiliki periode retensi minimum 90 hari pada log. |
| 3.2 | Ember S3 yang diamanatkan AMS yang menyimpan log harus memiliki periode retensi minimum 18 bulan pada log. |
| 3.3 | AWS Backup snapshot harus tersedia dengan retensi minimum 31 hari pada sumber daya yang didukung. |
| 4.0 | Enkripsi |
| 4.1 | Enkripsi harus diaktifkan di semua bucket S3 yang diperlukan oleh Tim AMS yang menyimpan log. |
| 4.2 | Setiap penerusan log dari akun pelanggan ke akun lain harus dienkripsi. |
| 5.0 | Integritas |
| 5.1 | Mekanisme integritas file log harus diaktifkan. “Validasi file log” harus dikonfigurasi di AWS CloudTrail jalur yang diperlukan oleh tim AMS. |
| 6.0 | Penerusan log |
| 6.1 | Setiap log dapat diteruskan dari satu akun AMS ke akun AMS lain dari pelanggan yang sama. |
| 6.2 | Setiap log dapat diteruskan dari AMS ke akun non-AMS hanya jika akun non-AMS dimiliki oleh pelanggan AMS yang sama. |
| 6.3 | Setiap log dari akun pelanggan tidak boleh diteruskan ke akun pihak ketiga (yang tidak dimiliki oleh pelanggan). |
Berikut ini adalah kontrol standar untuk 008 - AMS-MAD
| ID | Standar teknis |
|---|---|
| 1.0 | Manajemen Akses |
| 1.1 | Hanya pengguna istimewa AMS dengan login interaktif dan tugas otomatisasi yang harus diizinkan masuk ke host manajemen untuk administrasi AD terkelola di akun pelanggan. |
| 1.2 | Admin AD hanya boleh memiliki hak administrator yang didelegasikan (Grup Administrator Delegasi AMS). |
| 1.3 | Insinyur yang masuk ke lingkungan AD pelanggan (host manajemen atau instans) harus memiliki akses terikat waktu. |
| 1.4 | Pelanggan hanya membaca akses ke objek AD menggunakan Alat Administrator Server Jarak Jauh dalam sebuah EC2 instance. |
| 1.5 | Hak administratif untuk pengguna atau grup direktori aktif tidak boleh diizinkan. |
| 1.6 | AWS Berbagi direktori dengan yang Akun AWS dimiliki oleh pelanggan yang sama diperbolehkan dengan pemberitahuan risiko. |
| 2.0 | Akun layanan |
| 2.1 | Akun Layanan Terkelola Grup (GMSA) harus digunakan di mana pun didukung oleh aplikasi, bukan akun layanan standar. |
| 2.2 | Semua akun layanan lainnya harus dibuat setelah proses penerimaan risiko. |
| 2.3 | Grup Keamanan AD tidak boleh digunakan kembali kecuali diminta secara eksplisit oleh pelanggan. Grup AD baru harus dibuat. Objek komputer yang meminta akses ke akun layanan harus ditambahkan ke grup keamanan baru. |
| 2.4 | Setiap akun layanan GMSA harus ditambahkan di bawah Unit Organisasi (OU) “Akun Layanan Terkelola”. |
| 2.5 | Setiap akun layanan non-GMSA harus ditambahkan di bawah OU “Pengguna → Akun Layanan”. |
| 3.0 | Objek Kebijakan Grup (GPO) |
| 3.1 | Pengaturan apa pun di bawah GPO “Pengaturan Windows> Pengaturan Keamanan” tidak boleh dimodifikasi jika mengurangi postur keamanan akun dengan cara apa pun dari keadaan saat ini. |
| 3.2 | Di MALZ, RFCs dikirimkan dari akun aplikasi yang meminta pembuatan GPO, GPO harus ditautkan ke OU yang sesuai dengan akun Aplikasi. Semua GPOs yang memengaruhi semua akun harus berasal dari akun Layanan Bersama. |
| 3.3 | Waktu habis Sesi Idle RDP default harus diatur ke 15 menit untuk semua server di bawah domain direktori aktif. |
| 4.0 | Kepercayaan Direktori Aktif |
| 4.1 | Kepercayaan keluar satu arah (Direktori yang di-host AMS ke Direktori Pelanggan) diizinkan jika forwarder bersyarat dialihkan ke VPC melalui DX, VPC-peer, atau VPN. IPs |
| 5.0 | Lainnya |
| 5.1 | Mekanisme integritas file log harus diaktifkan. “Validasi file log” harus dikonfigurasi di AWS CloudTrail jalur yang diperlukan oleh tim AMS. |
| 6.0 | Penerusan log |
| 6.1 | Pengguna pelanggan, grup, objek komputer, OU atau entitas lain tidak boleh menggunakan konvensi penamaan AMS sesuai konvensi penamaan AMS. |
| 6.2 | Semua OUs harus dikelola oleh AMS. |
Berikut ini adalah kontrol standar untuk 009 - Miscellaneous
Jika enkripsi diaktifkan dalam sumber daya, objek, database, atau sistem file, itu tidak boleh dinonaktifkan.
