Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Keamanan di AWS Lambda
Keamanan cloud di AWS adalah prioritas tertinggi. Sebagai AWS pelanggan, Anda mendapat manfaat dari pusat data dan arsitektur jaringan yang dibangun untuk memenuhi persyaratan organisasi yang paling sensitif terhadap keamanan.
Keamanan adalah tanggung jawab bersama antara Anda AWS dan Anda. [Model tanggung jawab bersama](https://aws.amazon.com/compliance/shared-responsibility-model/) menggambarkan hal ini sebagai keamanan *dari* cloud dan keamanan *di* cloud:
+ **Keamanan cloud** — AWS bertanggung jawab untuk melindungi infrastruktur yang berjalan Layanan AWS di AWS Cloud. AWS juga memberi Anda layanan yang dapat Anda gunakan dengan aman. Auditor pihak ketiga secara berkala menguji dan memverifikasi efektivitas keamanan kami sebagai bagian dari [Program kepatuhan AWS](https://aws.amazon.com/compliance/programs/). Untuk mempelajari tentang program kepatuhan yang berlaku AWS Lambda, lihat [Layanan AWS di Cakupan berdasarkan Program Kepatuhan](https://aws.amazon.com/compliance/services-in-scope/).
+ **Keamanan di cloud** – Tanggung jawab Anda ditentukan menurut layanan AWS yang Anda gunakan. Anda juga bertanggung jawab atas faktor lain termasuk sensitivitas data Anda, persyaratan perusahaan Anda, serta hukum dan peraturan yang berlaku.
Dokumentasi ini membantu Anda memahami cara menerapkan model tanggung jawab bersama saat menggunakan Lambda. Topik berikut menunjukkan kepada Anda cara mengonfigurasi Lambda untuk memenuhi tujuan keamanan dan kepatuhan Anda. Anda juga mempelajari cara menggunakan Layanan AWS yang lain yang membantu Anda memantau dan mengamankan sumber daya Lambda Anda.
Untuk informasi selengkapnya tentang penerapan prinsip keamanan pada aplikasi Lambda, lihat [Keamanan di Tanah Tanpa](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops) Server.
**Topics**
+ [Perlindungan data di AWS Lambda](security-dataprotection.md)
+ [Menggunakan peran terkait layanan untuk Lambda](using-service-linked-roles.md)
+ [Identity and Access Management untuk AWS Lambda](security-iam.md)
+ [Buat strategi tata kelola untuk fungsi dan lapisan Lambda](governance-concepts.md)
+ [Validasi kepatuhan untuk AWS Lambda](security-compliance.md)
+ [Ketahanan di AWS Lambda](security-resilience.md)
+ [Keamanan infrastruktur di AWS Lambda](security-infrastructure.md)
+ [Mengamankan beban kerja dengan titik akhir publik](security-public-endpoints.md)
+ [Menggunakan penandatanganan kode untuk memverifikasi integritas kode dengan Lambda](configuration-codesigning.md)
# Perlindungan data di AWS Lambda
[Model tanggung jawab AWS bersama model](https://aws.amazon.com/compliance/shared-responsibility-model/) berlaku untuk perlindungan data di AWS Lambda. Seperti yang dijelaskan dalam model AWS ini, bertanggung jawab untuk melindungi infrastruktur global yang menjalankan semua AWS Cloud. Anda bertanggung jawab untuk mempertahankan kendali atas konten yang di-host pada infrastruktur ini. Anda juga bertanggung jawab atas tugas-tugas konfigurasi dan manajemen keamanan untuk Layanan AWS yang Anda gunakan. Lihat informasi yang lebih lengkap tentang privasi data dalam [Pertanyaan Umum Privasi Data](https://aws.amazon.com/compliance/data-privacy-faq/). Lihat informasi tentang perlindungan data di Eropa di pos blog [Model Tanggung Jawab Bersama dan GDPR AWS](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) di *Blog Keamanan AWS *.
Untuk tujuan perlindungan data, kami menyarankan Anda melindungi Akun AWS kredensyal dan mengatur pengguna individu dengan AWS IAM Identity Center atau AWS Identity and Access Management (IAM). Dengan cara itu, setiap pengguna hanya diberi izin yang diperlukan untuk memenuhi tanggung jawab tugasnya. Kami juga menyarankan supaya Anda mengamankan data dengan cara-cara berikut:
+ Gunakan autentikasi multi-faktor (MFA) pada setiap akun.
+ Gunakan SSL/TLS untuk berkomunikasi dengan sumber daya. AWS Kami mensyaratkan TLS 1.2 dan menganjurkan TLS 1.3.
+ Siapkan API dan pencatatan aktivitas pengguna dengan AWS CloudTrail. Untuk informasi tentang penggunaan CloudTrail jejak untuk menangkap AWS aktivitas, lihat [Bekerja dengan CloudTrail jejak](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) di *AWS CloudTrail Panduan Pengguna*.
+ Gunakan solusi AWS enkripsi, bersama dengan semua kontrol keamanan default di dalamnya Layanan AWS.
+ Gunakan layanan keamanan terkelola tingkat lanjut seperti Amazon Macie, yang membantu menemukan dan mengamankan data sensitif yang disimpan di Amazon S3.
+ Jika Anda memerlukan modul kriptografi tervalidasi FIPS 140-3 saat mengakses AWS melalui antarmuka baris perintah atau API, gunakan titik akhir FIPS. Lihat informasi selengkapnya tentang titik akhir FIPS yang tersedia di [Standar Pemrosesan Informasi Federal (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Kami sangat merekomendasikan agar Anda tidak pernah memasukkan informasi identifikasi yang sensitif, seperti nomor rekening pelanggan Anda, ke dalam tanda atau bidang isian bebas seperti bidang **Nama**. Ini termasuk saat Anda bekerja dengan Lambda atau lainnya Layanan AWS menggunakan konsol, API AWS CLI, atau. AWS SDKs Data apa pun yang Anda masukkan ke dalam tanda atau bidang isian bebas yang digunakan untuk nama dapat digunakan untuk log penagihan atau log diagnostik. Saat Anda memberikan URL ke server eksternal, kami sangat menganjurkan supaya Anda tidak menyertakan informasi kredensial di dalam URL untuk memvalidasi permintaan Anda ke server itu.
**Topics**
+ [Enkripsi dalam transit](#security-privacy-intransit)
+ [Enkripsi data saat istirahat untuk AWS Lambda](security-encryption-at-rest.md)
## Enkripsi dalam transit
Titik akhir API Lambda hanya mendukung koneksi aman melalui HTTPS. Saat Anda mengelola sumber daya Lambda dengan Konsol Manajemen AWS,AWS SDK, atau Lambda API, semua komunikasi dienkripsi dengan Transport Layer Security (TLS). Untuk daftar lengkap titik akhir API, lihat [AWS Wilayah dan titik akhir](https://docs.aws.amazon.com/general/latest/gr/rande.html) di. Referensi Umum AWS
Saat Anda [menghubungkan fungsi Anda ke sistem file](configuration-filesystem.md), Lambda menggunakan enkripsi dalam perjalanan untuk semua koneksi. Untuk informasi selengkapnya, lihat [Enkripsi data di Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) di *Panduan Pengguna Amazon Elastic File System*.
Saat Anda menggunakan [variabel lingkungan](configuration-envvars.md), Anda dapat mengaktifkan pembantu enkripsi konsol untuk menggunakan enkripsi sisi klien untuk melindungi variabel lingkungan yang sedang transit. Untuk informasi selengkapnya, lihat [Mengamankan variabel lingkungan Lambda](configuration-envvars-encryption.md).
# Enkripsi data saat istirahat untuk AWS Lambda
Lambda selalu menyediakan enkripsi saat istirahat untuk sumber daya berikut menggunakan atau [Kunci milik AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk): [Kunci yang dikelola AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)
+ Variabel-variabel lingkungan
+ File yang Anda unggah ke Lambda, termasuk paket penerapan dan arsip lapisan
+ objek kriteria filter pemetaan sumber peristiwa
[Anda dapat mengonfigurasi Lambda secara opsional untuk menggunakan kunci terkelola pelanggan untuk mengenkripsi variabel [lingkungan](configuration-envvars-encryption.md), paket [penerapan .zip,](encrypt-zip-package.md) dan objek kriteria filter.](invocation-eventfiltering.md#filter-criteria-encryption)
Amazon CloudWatch Logs dan AWS X-Ray juga mengenkripsi data secara default, dan dapat dikonfigurasi untuk menggunakan kunci yang dikelola pelanggan. Untuk detailnya, lihat [Mengenkripsi data CloudWatch log di Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) dan [Perlindungan data di AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html).
## Memantau kunci enkripsi Anda untuk Lambda
Saat Anda menggunakan kunci yang dikelola AWS KMS pelanggan dengan Lambda, Anda dapat menggunakannya. [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) Contoh berikut adalah CloudTrail acara untuk`Decrypt`,`DescribeKey`, dan `GenerateDataKey` panggilan yang dilakukan oleh Lambda untuk mengakses data yang dienkripsi oleh kunci yang dikelola pelanggan Anda.
------
#### [ Decrypt ]
Jika Anda menggunakan kunci terkelola AWS KMS pelanggan untuk mengenkripsi objek [kriteria filter](invocation-eventfiltering.md#filter-criteria-encryption), Lambda mengirimkan `Decrypt` permintaan atas nama Anda saat Anda mencoba mengaksesnya dalam teks biasa (misalnya, dari panggilan). `ListEventSourceMappings` Contoh peristiwa berikut mencatat `Decrypt` operasi:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:05:46Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"sessionCredentialFromConsole": "true"
}
```
------
#### [ DescribeKey ]
Jika Anda menggunakan kunci terkelola AWS KMS pelanggan untuk mengenkripsi objek [kriteria filter](invocation-eventfiltering.md#filter-criteria-encryption), Lambda mengirimkan `DescribeKey` permintaan atas nama Anda saat Anda mencoba mengaksesnya (misalnya, dari `GetEventSourceMapping` panggilan). Contoh peristiwa berikut mencatat `DescribeKey` operasi:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-05-30T01:09:40Z",
"eventSource": "kms.amazonaws.com",
"eventName": "DescribeKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "54.240.197.238",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36",
"requestParameters": {
"keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_256_GCM_SHA384",
"clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com"
},
"sessionCredentialFromConsole": "true"
}
```
------
#### [ GenerateDataKey ]
Saat Anda menggunakan kunci yang dikelola AWS KMS pelanggan untuk mengenkripsi objek [kriteria filter](invocation-eventfiltering.md#filter-criteria-encryption) Anda dalam `UpdateEventSourceMapping` panggilan `CreateEventSourceMapping` atau, Lambda mengirimkan `GenerateDataKey` permintaan atas nama Anda untuk menghasilkan kunci data untuk mengenkripsi kriteria filter [(](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)enkripsi amplop). Contoh peristiwa berikut mencatat `GenerateDataKey` operasi:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:06:07Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:04:18Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"numberOfBytes": 32,
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
------
# Menggunakan peran terkait layanan untuk Lambda
[Lambda menggunakan peran terkait AWS Identity and Access Management layanan (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Peran terkait layanan adalah jenis peran IAM unik yang ditautkan langsung ke Lambda. Peran terkait layanan telah ditentukan sebelumnya oleh Lambda dan menyertakan izin yang diperlukan layanan untuk memanggil layanan lain atas nama Anda. AWS
Lambda mendefinisikan izin peran terkait layanan, dan hanya Lambda yang dapat mengambil perannya. Izin yang ditentukan mencakup kebijakan kepercayaan dan kebijakan izin, dan kebijakan izin tersebut tidak dapat dilampirkan ke entitas IAM lainnya.
Anda dapat menghapus peran tertaut layanan hanya setelah menghapus sumber daya terkait terlebih dahulu. Ini melindungi sumber daya Lambda Anda karena Anda tidak dapat secara tidak sengaja menghapus izin untuk mengakses sumber daya.
Untuk informasi tentang layanan lain yang mendukung peran terkait layanan, silakan lihat [layanan AWS yang bisa digunakan dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dan carilah layanan yang memiliki opsi **Ya** di kolom **Peran terkait layanan**. Pilih **Ya** dengan sebuah tautan untuk melihat dokumentasi peran terkait layanan untuk layanan tersebut.
## Izin peran terkait layanan untuk Lambda
Lambda menggunakan peran terkait layanan bernama. **AWSServiceRoleForLambda** Peran tertaut layanan memercayai layanan berikut untuk mengambil peran tersebut:
+ `lambda.amazonaws.com`
Kebijakan izin peran bernama AWSLambda ServiceRolePolicy memungkinkan Lambda menyelesaikan tindakan berikut pada sumber daya yang ditentukan:
+ Tindakan: `ec2:TerminateInstances` `arn:aws:ec2:*:*:instance/*` dengan kondisi yang `ec2:ManagedResourceOperator` sama `scaler.lambda.amazonaws.com`
+ Aksi: `ec2:DescribeInstanceStatus` dan `ec2:DescribeInstances` seterusnya `*`
Anda harus mengonfigurasi izin agar pengguna, grup, atau peran Anda membuat, mengedit, atau menghapus peran terkait layanan. Untuk informasi selengkapnya, lihat [Izin peran terkait layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dalam *Panduan Pengguna IAM*.
Untuk pembaruan kebijakan terkelola, lihat Kebijakan [terkelola Lambda](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates).
## Membuat peran terkait layanan untuk Lambda
Anda tidak perlu membuat peran terkait layanan secara manual. Saat Anda membuat penyedia kapasitas Lambda di, API Konsol Manajemen AWS, atau AWS API AWS CLI, Lambda membuat peran terkait layanan untuk Anda.
Jika Anda menghapus peran terkait layanan ini, dan ingin membuatnya lagi, Anda dapat mengulangi proses yang sama untuk membuat kembali peran tersebut di akun Anda. Saat Anda membuat penyedia kapasitas Lambda, Lambda membuat peran terkait layanan untuk Anda lagi.
Anda juga dapat menggunakan konsol IAM untuk membuat peran terkait layanan dengan kasus penggunaan. **AWSServiceRoleForLambda** Di AWS CLI atau AWS API, buat peran terkait layanan dengan nama `lambda.amazonaws.com` layanan. Untuk informasi selengkapnya, lihat [Membuat peran tertaut layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) dalam *Panduan Pengguna IAM*. Jika Anda menghapus peran tertaut layanan ini, Anda dapat mengulang proses yang sama untuk membuat peran tersebut lagi.
## Mengedit peran terkait layanan untuk Lambda
Lambda tidak mengizinkan Anda mengedit peran terkait AWSService RoleForLambda layanan. Setelah membuat peran terkait layanan, Anda tidak dapat mengubah nama peran karena berbagai entitas mungkin merujuk peran tersebut. Namun, Anda dapat mengedit penjelasan peran menggunakan IAM. Untuk informasi selengkapnya, lihat [Mengedit peran terkait layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dalam *Panduan Pengguna IAM*.
## Menghapus peran terkait layanan untuk Lambda
Jika Anda tidak perlu lagi menggunakan fitur atau layanan yang memerlukan peran terkait layanan, sebaiknya hapus peran tersebut. Dengan begitu, Anda tidak memiliki entitas yang tidak digunakan yang tidak dipantau atau dipelihara secara aktif. Tetapi, Anda harus membersihkan sumber daya peran yang terhubung dengan layanan sebelum menghapusnya secara manual.
**catatan**
Jika layanan Lambda menggunakan peran saat Anda mencoba menghapus sumber daya, maka penghapusan mungkin gagal. Jika hal itu terjadi, tunggu beberapa menit dan coba mengoperasikannya lagi.
**Untuk menghapus sumber daya Lambda yang digunakan oleh AWSService RoleForLambda**
1. Hapus semua penyedia kapasitas Lambda dari akun Anda. Anda dapat melakukan ini menggunakan konsol Lambda, CLI, atau API.
1. Pastikan tidak ada penyedia kapasitas Lambda yang tetap berada di akun Anda sebelum mencoba menghapus peran terkait layanan.
**Untuk menghapus peran tertaut layanan secara manual menggunakan IAM**
Gunakan konsol IAM, the AWS CLI, atau AWS API untuk menghapus peran AWSService RoleForLambda terkait layanan. Untuk informasi selengkapnya, lihat [Menghapus peran terkait layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dalam *Panduan Pengguna IAM*.
## Wilayah yang Didukung untuk peran terkait layanan Lambda
Lambda tidak mendukung penggunaan peran terkait layanan di setiap Wilayah tempat layanan tersedia. AWSServiceRoleForLambda didukung di Wilayah berikut.
| Nama wilayah | Identitas wilayah | Support di Lambda |
| --- | --- | --- |
| US East (Northern Virginia) | us-east-1 | Ya |
| US East (Ohio) | us-east-2 | Ya |
| US West (N. California) | us-west-1 | Ya |
| US West (Oregon) | us-west-2 | Ya |
| Africa (Cape Town) | af-south-1 | Tidak |
| Asia Pasifik (Hong Kong) | ap-east-1 | Ya |
| Asia Pasifik (Jakarta) | ap-southeast-3 | Ya |
| Asia Pasifik (Bangkok) | ap-tenggara 7 | Ya |
| Asia Pacific (Mumbai) | ap-south-1 | Ya |
| Asia Pacific (Osaka) | ap-northeast-3 | Tidak |
| Asia Pasifik (Seoul) | ap-northeast-2 | Tidak |
| Asia Pasifik (Singapura) | ap-southeast-1 | Ya |
| Asia Pacific (Sydney) | ap-southeast-2 | Ya |
| Asia Pacific (Tokyo) | ap-northeast-1 | Ya |
| Canada (Central) | ca-central-1 | Tidak |
| Eropa (Frankfurt) | eu-central-1 | Ya |
| Eropa (Irlandia) | eu-west-1 | Ya |
| Eropa (London) | eu-west-2 | Ya |
| Europe (Milan) | eu-south-1 | Tidak |
| Eropa (Paris) | eu-west-3 | Tidak |
| Eropa (Stockholm) | eu-north-1 | Tidak |
| Timur Tengah (Bahrain) | me-south-1 | Tidak |
| Timur Tengah (UAE) | me-central-1 | Tidak |
| Amerika Selatan (Sao Paulo) | sa-east-1 | Tidak |
| AWS GovCloud (AS-Timur) | us-gov-east-1 | Tidak |
| AWS GovCloud (AS-Barat) | us-gov-west-1 | Tidak |
# Identity and Access Management untuk AWS Lambda
AWS Identity and Access Management (IAM) adalah Layanan AWS yang membantu administrator mengontrol akses ke AWS sumber daya dengan aman. Administrator IAM mengontrol siapa yang dapat *diautentikasi* (masuk) dan *diotorisasi* (memiliki izin) untuk menggunakan sumber daya Lambda. IAM adalah Layanan AWS yang dapat Anda gunakan tanpa biaya tambahan.
**Topics**
+ [Audiens](#security_iam_audience)
+ [Mengautentikasi dengan identitas](#security_iam_authentication)
+ [Mengelola akses menggunakan kebijakan](#security_iam_access-manage)
+ [Bagaimana AWS Lambda bekerja dengan IAM](security_iam_service-with-iam.md)
+ [Contoh kebijakan berbasis identitas untuk AWS Lambda](security_iam_id-based-policy-examples.md)
+ [AWS kebijakan terkelola untuk AWS Lambda](security-iam-awsmanpol.md)
+ [Memecahkan masalah AWS Lambda identitas dan akses](security_iam_troubleshoot.md)
## Audiens
Cara Anda menggunakan AWS Identity and Access Management (IAM) berbeda berdasarkan peran Anda:
+ **Pengguna layanan** - minta izin dari administrator Anda jika Anda tidak dapat mengakses fitur (lihat [Memecahkan masalah AWS Lambda identitas dan akses](security_iam_troubleshoot.md))
+ **Administrator layanan** - tentukan akses pengguna dan mengirimkan permintaan izin (lihat [Bagaimana AWS Lambda bekerja dengan IAM](security_iam_service-with-iam.md))
+ **Administrator IAM** - tulis kebijakan untuk mengelola akses (lihat [Contoh kebijakan berbasis identitas untuk AWS Lambda](security_iam_id-based-policy-examples.md))
## Mengautentikasi dengan identitas
Otentikasi adalah cara Anda masuk AWS menggunakan kredensi identitas Anda. Anda harus diautentikasi sebagai Pengguna root akun AWS, pengguna IAM, atau dengan mengasumsikan peran IAM.
Anda dapat masuk sebagai identitas federasi menggunakan kredensional dari sumber identitas seperti AWS IAM Identity Center (Pusat Identitas IAM), autentikasi masuk tunggal, atau kredensional. Google/Facebook Untuk informasi selengkapnya tentang cara masuk, lihat [Cara masuk ke Akun AWS Anda](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dalam *Panduan Pengguna AWS Sign-In *.
Untuk akses terprogram, AWS sediakan SDK dan CLI untuk menandatangani permintaan secara kriptografis. Untuk informasi selengkapnya, lihat [AWS Signature Version 4 untuk permintaan API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dalam *Panduan Pengguna IAM*.
### Akun AWS pengguna root
Saat Anda membuat Akun AWS, Anda mulai dengan satu identitas masuk yang disebut *pengguna Akun AWS root* yang memiliki akses lengkap ke semua Layanan AWS dan sumber daya. Kami sangat menyarankan agar Anda tidak menggunakan pengguna root untuk tugas sehari-hari. Untuk tugas yang memerlukan kredensial pengguna root, lihat [Tugas yang memerlukan kredensial pengguna root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dalam *Panduan Pengguna IAM*.
### Identitas terfederasi
Sebagai praktik terbaik, mewajibkan pengguna manusia untuk menggunakan federasi dengan penyedia identitas untuk mengakses Layanan AWS menggunakan kredensi sementara.
*Identitas federasi* adalah pengguna dari direktori perusahaan Anda, penyedia identitas web, atau Directory Service yang mengakses Layanan AWS menggunakan kredensi dari sumber identitas. Identitas terfederasi mengambil peran yang memberikan kredensial sementara.
Untuk manajemen akses terpusat, kami menyarankan AWS IAM Identity Center. Untuk informasi selengkapnya, lihat [Apa itu Pusat Identitas IAM?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) dalam *Panduan Pengguna AWS IAM Identity Center *.
### Pengguna dan grup IAM
*[Pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* adalah identitas dengan izin khusus untuk satu orang atau aplikasi. Sebaiknya gunakan kredensial sementara alih-alih pengguna IAM dengan kredensial jangka panjang. Untuk informasi selengkapnya, lihat [Mewajibkan pengguna manusia untuk menggunakan federasi dengan penyedia identitas untuk mengakses AWS menggunakan kredensi sementara](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) di Panduan Pengguna *IAM*.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) menentukan kumpulan pengguna IAM dan mempermudah pengelolaan izin untuk pengguna dalam jumlah besar. Untuk mempelajari selengkapnya, lihat [Kasus penggunaan untuk pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dalam *Panduan Pengguna IAM*.
### Peran IAM
*[Peran IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* adalah identitas dengan izin khusus yang menyediakan kredensial sementara. Anda dapat mengambil peran dengan [beralih dari pengguna ke peran IAM (konsol)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) atau dengan memanggil operasi AWS CLI atau AWS API. Untuk informasi selengkapnya, lihat [Metode untuk mengambil peran](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dalam *Panduan Pengguna IAM*.
Peran IAM berguna untuk akses pengguna terfederasi, izin pengguna IAM sementara, akses lintas akun, akses lintas layanan, dan aplikasi yang berjalan di Amazon EC2. Untuk informasi selengkapnya, lihat [Akses sumber daya lintas akun di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dalam *Panduan Pengguna IAM*.
## Mengelola akses menggunakan kebijakan
Anda mengontrol akses AWS dengan membuat kebijakan dan melampirkannya ke AWS identitas atau sumber daya. Kebijakan menentukan izin saat dikaitkan dengan identitas atau sumber daya. AWS mengevaluasi kebijakan ini ketika kepala sekolah membuat permintaan. Sebagian besar kebijakan disimpan AWS sebagai dokumen JSON. Untuk informasi selengkapnya tentang dokumen kebijakan JSON, lihat [Gambaran umum kebijakan JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dalam *Panduan Pengguna IAM*.
Menggunakan kebijakan, administrator menentukan siapa yang memiliki akses ke apa dengan mendefinisikan **principal** mana yang dapat melakukan **tindakan** pada **sumber daya** apa, dan dalam **kondisi** apa.
Secara default, pengguna dan peran tidak memiliki izin. Administrator IAM membuat kebijakan IAM dan menambahkannya ke peran, yang kemudian dapat diambil oleh pengguna. Kebijakan IAM mendefinisikan izin terlepas dari metode yang Anda gunakan untuk melakukan operasinya.
### Kebijakan berbasis identitas
Kebijakan berbasis identitas adalah dokumen kebijakan izin JSON yang Anda lampirkan ke identitas (pengguna, grup, atau peran). Kebijakan ini mengontrol tindakan apa yang bisa dilakukan oleh identitas tersebut, terhadap sumber daya yang mana, dan dalam kondisi apa. Untuk mempelajari cara membuat kebijakan berbasis identitas, lihat [Tentukan izin IAM kustom dengan kebijakan yang dikelola pelanggan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dalam *Panduan Pengguna IAM*.
Kebijakan berbasis identitas dapat berupa *kebijakan inline* (disematkan langsung ke dalam satu identitas) atau *kebijakan terkelola* (kebijakan mandiri yang dilampirkan pada banyak identitas). Untuk mempelajari cara memilih antara kebijakan terkelola dan kebijakan inline, lihat [Pilih antara kebijakan terkelola dan kebijakan inline](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dalam *Panduan Pengguna IAM*.
### Kebijakan berbasis sumber daya
Kebijakan berbasis sumber daya adalah dokumen kebijakan JSON yang Anda lampirkan ke sumber daya. Contohnya termasuk *kebijakan kepercayaan peran IAM* dan *kebijakan bucket* Amazon S3. Dalam layanan yang mendukung kebijakan berbasis sumber daya, administrator layanan dapat menggunakannya untuk mengontrol akses ke sumber daya tertentu. Anda harus [menentukan principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dalam kebijakan berbasis sumber daya.
Kebijakan berbasis sumber daya merupakan kebijakan inline yang terletak di layanan tersebut. Anda tidak dapat menggunakan kebijakan AWS terkelola dari IAM dalam kebijakan berbasis sumber daya.
### Jenis-jenis kebijakan lain
AWS mendukung jenis kebijakan tambahan yang dapat menetapkan izin maksimum yang diberikan oleh jenis kebijakan yang lebih umum:
+ **Batasan izin** – Menetapkan izin maksimum yang dapat diberikan oleh kebijakan berbasis identitas kepada entitas IAM. Untuk informasi selengkapnya, lihat [Batasan izin untuk entitas IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dalam *Panduan Pengguna IAM*.
+ **Kebijakan kontrol layanan (SCPs)** — Tentukan izin maksimum untuk organisasi atau unit organisasi di AWS Organizations. Untuk informasi selengkapnya, lihat [Kebijakan kontrol layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dalam *Panduan Pengguna AWS Organizations *.
+ **Kebijakan kontrol sumber daya (RCPs)** — Tetapkan izin maksimum yang tersedia untuk sumber daya di akun Anda. Untuk informasi selengkapnya, lihat [Kebijakan kontrol sumber daya (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) di *Panduan AWS Organizations Pengguna*.
+ **Kebijakan sesi** – Kebijakan lanjutan yang diteruskan sebagai parameter saat membuat sesi sementara untuk peran atau pengguna terfederasi. Untuk informasi selengkapnya, lihat [Kebijakan sesi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dalam *Panduan Pengguna IAM*.
### Berbagai jenis kebijakan
Ketika beberapa jenis kebijakan berlaku pada suatu permintaan, izin yang dihasilkan lebih rumit untuk dipahami. Untuk mempelajari cara AWS menentukan apakah akan mengizinkan permintaan saat beberapa jenis kebijakan terlibat, lihat [Logika evaluasi kebijakan](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) di *Panduan Pengguna IAM*.
# Bagaimana AWS Lambda bekerja dengan IAM
Sebelum Anda menggunakan IAM untuk mengelola akses ke Lambda, pelajari fitur IAM apa yang tersedia untuk digunakan dengan Lambda.
| Fitur IAM | Dukungan Lambda |
| --- | --- |
| [Kebijakan berbasis identitas](#security_iam_service-with-iam-id-based-policies) | Ya |
| [Kebijakan berbasis sumber daya](#security_iam_service-with-iam-resource-based-policies) | Ya |
| [Tindakan kebijakan](#security_iam_service-with-iam-id-based-policies-actions) | Ya |
| [Sumber daya kebijakan](#security_iam_service-with-iam-id-based-policies-resources) | Ya |
| [kunci-kunci persyaratan kebijakan (spesifik layanan)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Ya |
| [ACLs](#security_iam_service-with-iam-acls) | Tidak |
| [ABAC (tanda dalam kebijakan)](#security_iam_service-with-iam-tags) | Parsial |
| [Kredensial sementara](#security_iam_service-with-iam-roles-tempcreds) | Ya |
| [Sesi akses teruskan (FAS)](#security_iam_service-with-iam-principal-permissions) | Tidak |
| [Peran layanan](#security_iam_service-with-iam-roles-service) | Ya |
| [Peran terkait layanan](#security_iam_service-with-iam-roles-service-linked) | Parsial |
*Untuk mendapatkan tampilan tingkat tinggi tentang cara kerja Lambda dan layanan AWS lainnya dengan sebagian besar fitur IAM, [AWS lihat layanan yang bekerja dengan IAM di Panduan Pengguna](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) IAM.*
## Kebijakan berbasis identitas untuk Lambda
**Mendukung kebijakan berbasis identitas**: Ya
Kebijakan berbasis identitas adalah dokumen kebijakan izin JSON yang dapat Anda lampirkan ke sebuah identitas, seperti pengguna IAM, grup pengguna IAM, atau peran IAM. Kebijakan ini mengontrol jenis tindakan yang dapat dilakukan oleh pengguna dan peran, di sumber daya mana, dan berdasarkan kondisi seperti apa. Untuk mempelajari cara membuat kebijakan berbasis identitas, lihat [Tentukan izin IAM kustom dengan kebijakan terkelola pelanggan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dalam *Panduan Pengguna IAM*.
Dengan kebijakan berbasis identitas IAM, Anda dapat menentukan secara spesifik apakah tindakan dan sumber daya diizinkan atau ditolak, serta kondisi yang menjadi dasar dikabulkan atau ditolaknya tindakan tersebut. Untuk mempelajari semua elemen yang dapat Anda gunakan dalam kebijakan JSON, lihat [Referensi elemen kebijakan JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dalam *Panduan Pengguna IAM*.
### Contoh kebijakan berbasis identitas untuk Lambda
Untuk melihat contoh kebijakan berbasis identitas Lambda, lihat. [Contoh kebijakan berbasis identitas untuk AWS Lambda](security_iam_id-based-policy-examples.md)
## Kebijakan berbasis sumber daya dalam Lambda
**Mendukung kebijakan berbasis sumber daya**: Ya
Kebijakan berbasis sumber daya adalah dokumen kebijakan JSON yang Anda lampirkan ke sumber daya. Contoh kebijakan berbasis sumber daya adalah *kebijakan kepercayaan peran* IAM dan *kebijakan bucket* Amazon S3. Dalam layanan yang mendukung kebijakan berbasis sumber daya, administrator layanan dapat menggunakannya untuk mengontrol akses ke sumber daya tertentu. Untuk sumber daya tempat kebijakan dilampirkan, kebijakan menentukan tindakan apa yang dapat dilakukan oleh principal tertentu pada sumber daya tersebut dan dalam kondisi apa. Anda harus [menentukan principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dalam kebijakan berbasis sumber daya. Prinsipal dapat mencakup akun, pengguna, peran, pengguna federasi, atau. Layanan AWS
Untuk mengaktifkan akses lintas akun, Anda dapat menentukan secara spesifik seluruh akun atau entitas IAM di akun lain sebagai principal dalam kebijakan berbasis sumber daya. Untuk informasi selengkapnya, lihat [Akses sumber daya lintas akun di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dalam *Panduan Pengguna IAM*.
Anda dapat melampirkan kebijakan berbasis sumber daya ke fungsi atau lapisan Lambda. Kebijakan ini mendefinisikan prinsipal mana yang dapat melakukan tindakan pada fungsi atau lapisan.
Untuk mempelajari cara melampirkan kebijakan berbasis sumber daya ke fungsi atau lapisan, lihat. [Melihat kebijakan IAM berbasis sumber daya di Lambda](access-control-resource-based.md)
## Tindakan kebijakan untuk Lambda
**Mendukung tindakan kebijakan:** Ya
Administrator dapat menggunakan kebijakan AWS JSON untuk menentukan siapa yang memiliki akses ke apa. Yaitu, di mana **utama** dapat melakukan **tindakan** pada **sumber daya**, dan dalam **kondisi apa**.
Elemen `Action` dari kebijakan JSON menjelaskan tindakan yang dapat Anda gunakan untuk mengizinkan atau menolak akses dalam sebuah kebijakan. Sertakan tindakan dalam kebijakan untuk memberikan izin untuk melakukan operasi terkait.
Untuk melihat daftar tindakan Lambda, lihat [Tindakan yang ditentukan oleh AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions) dalam Referensi *Otorisasi Layanan*.
Tindakan kebijakan di Lambda menggunakan awalan berikut sebelum tindakan:
```
lambda
```
Untuk menetapkan secara spesifik beberapa tindakan dalam satu pernyataan, pisahkan tindakan tersebut dengan koma.
```
"Action": [
"lambda:action1",
"lambda:action2"
]
```
Untuk melihat contoh kebijakan berbasis identitas Lambda, lihat. [Contoh kebijakan berbasis identitas untuk AWS Lambda](security_iam_id-based-policy-examples.md)
## Sumber daya kebijakan untuk Lambda
**Mendukung sumber daya kebijakan:** Ya
Administrator dapat menggunakan kebijakan AWS JSON untuk menentukan siapa yang memiliki akses ke apa. Yaitu, di mana **utama** dapat melakukan **tindakan** pada **sumber daya**, dan dalam **kondisi apa**.
Elemen kebijakan JSON `Resource` menentukan objek yang menjadi target penerapan tindakan. Praktik terbaiknya, tentukan sumber daya menggunakan [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Untuk tindakan yang tidak mendukung izin di tingkat sumber daya, gunakan wildcard (\$1) untuk menunjukkan bahwa pernyataan tersebut berlaku untuk semua sumber daya.
```
"Resource": "*"
```
Untuk melihat daftar jenis sumber daya Lambda dan jenis sumber daya Lambda ARNs, lihat [Jenis sumber daya yang ditentukan oleh AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies) dalam Referensi *Otorisasi Layanan*. Untuk mempelajari dengan tindakan mana Anda dapat menentukan ARN setiap sumber daya, lihat [Tindakan yang ditentukan oleh AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Untuk melihat contoh kebijakan berbasis identitas Lambda, lihat. [Contoh kebijakan berbasis identitas untuk AWS Lambda](security_iam_id-based-policy-examples.md)
## Kunci kondisi kebijakan untuk Lambda
**Mendukung kunci kondisi kebijakan khusus layanan:** Yes
Administrator dapat menggunakan kebijakan AWS JSON untuk menentukan siapa yang memiliki akses ke apa. Yaitu, **principal** dapat melakukan **tindakan** pada suatu **sumber daya**, dan dalam suatu **syarat**.
Elemen `Condition` menentukan ketika pernyataan dieksekusi berdasarkan kriteria yang ditetapkan. Anda dapat membuat ekspresi bersyarat yang menggunakan [operator kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), misalnya sama dengan atau kurang dari, untuk mencocokkan kondisi dalam kebijakan dengan nilai-nilai yang diminta. Untuk melihat semua kunci kondisi AWS global, lihat [kunci konteks kondisi AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) di *Panduan Pengguna IAM*.
Untuk melihat daftar kunci kondisi Lambda, lihat Kunci kondisi [untuk AWS Lambda Referensi](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys) *Otorisasi Layanan*. Untuk mempelajari tindakan dan sumber daya yang dapat Anda gunakan kunci kondisi, lihat [Tindakan yang ditentukan oleh AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Untuk melihat contoh kebijakan berbasis identitas Lambda, lihat. [Contoh kebijakan berbasis identitas untuk AWS Lambda](security_iam_id-based-policy-examples.md)
## ACLs di Lambda
**Mendukung ACLs:** Tidak
Access control lists (ACLs) mengontrol prinsipal mana (anggota akun, pengguna, atau peran) yang memiliki izin untuk mengakses sumber daya. ACLs mirip dengan kebijakan berbasis sumber daya, meskipun mereka tidak menggunakan format dokumen kebijakan JSON.
## ABAC dengan Lambda
**Mendukung ABAC (tag dalam kebijakan): Sebagian**
Kontrol akses berbasis atribut (ABAC) adalah strategi otorisasi yang menentukan izin berdasarkan atribut tanda. Anda dapat melampirkan tag ke entitas dan AWS sumber daya IAM, lalu merancang kebijakan ABAC untuk mengizinkan operasi saat tag prinsipal cocok dengan tag pada sumber daya.
Untuk mengendalikan akses berdasarkan tanda, berikan informasi tentang tanda di [elemen kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dari kebijakan menggunakan kunci kondisi `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, atau `aws:TagKeys`.
Jika sebuah layanan mendukung ketiga kunci kondisi untuk setiap jenis sumber daya, nilainya adalah **Ya** untuk layanan tersebut. Jika suatu layanan mendukung ketiga kunci kondisi untuk hanya beberapa jenis sumber daya, nilainya adalah **Parsial**.
Untuk informasi selengkapnya tentang ABAC, lihat [Tentukan izin dengan otorisasi ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dalam *Panduan Pengguna IAM.* Untuk melihat tutorial yang menguraikan langkah-langkah pengaturan ABAC, lihat [Menggunakan kontrol akses berbasis atribut (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dalam *Panduan Pengguna IAM*.
Untuk informasi selengkapnya tentang menandai sumber daya Lambda, lihat. [Menggunakan kontrol akses berbasis atribut di Lambda](attribute-based-access-control.md)
## Menggunakan kredensil sementara dengan Lambda
**Mendukung kredensial sementara:** Ya
Kredensi sementara menyediakan akses jangka pendek ke AWS sumber daya dan secara otomatis dibuat saat Anda menggunakan federasi atau beralih peran. AWS merekomendasikan agar Anda secara dinamis menghasilkan kredensi sementara alih-alih menggunakan kunci akses jangka panjang. Untuk informasi selengkapnya, lihat [Kredensial keamanan sementara di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) dan [Layanan AWS yang berfungsi dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dalam *Panduan Pengguna IAM*.
## Teruskan sesi akses untuk Lambda
**Mendukung sesi akses maju (FAS): Tidak**
Sesi akses teruskan (FAS) menggunakan izin dari pemanggilan utama Layanan AWS, dikombinasikan dengan permintaan Layanan AWS untuk membuat permintaan ke layanan hilir. Untuk detail kebijakan ketika mengajukan permintaan FAS, lihat [Sesi akses terusan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Peran layanan untuk Lambda
**Mendukung peran layanan:** Ya
Peran layanan adalah [peran IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) yang diambil oleh sebuah layanan untuk melakukan tindakan atas nama Anda. Administrator IAM dapat membuat, mengubah, dan menghapus peran layanan dari dalam IAM. Untuk informasi selengkapnya, lihat [Buat sebuah peran untuk mendelegasikan izin ke Layanan AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dalam *Panduan pengguna IAM*.
Di Lambda, peran layanan dikenal sebagai peran [eksekusi](lambda-intro-execution-role.md).
**Awas**
Mengubah izin untuk peran eksekusi dapat merusak fungsionalitas Lambda.
## Peran terkait layanan untuk Lambda
**Mendukung peran terkait layanan**: Sebagian
Peran terkait layanan adalah jenis peran layanan yang ditautkan ke. Layanan AWS Layanan tersebut dapat menjalankan peran untuk melakukan tindakan atas nama Anda. Peran terkait layanan muncul di Anda Akun AWS dan dimiliki oleh layanan. Administrator IAM dapat melihat, tetapi tidak dapat mengedit izin untuk peran terkait layanan.
Lambda tidak memiliki peran terkait layanan, tetapi Lambda @Edge memilikinya. *Untuk informasi selengkapnya, lihat [Peran Tertaut Layanan untuk Lambda @Edge di Panduan Pengembang](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles) Amazon. CloudFront *
Untuk detail tentang pembuatan atau manajemen peran terkait layanan, lihat [Layanan AWS yang berfungsi dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Cari layanan dalam tabel yang memiliki `Yes` di kolom **Peran terkait layanan**. Pilih tautan **Ya** untuk melihat dokumentasi peran terkait layanan untuk layanan tersebut.
# Contoh kebijakan berbasis identitas untuk AWS Lambda
Secara default, pengguna dan peran tidak memiliki izin untuk membuat atau memodifikasi sumber daya Lambda. Untuk memberikan izin kepada pengguna untuk melakukan tindakan di sumber daya yang mereka perlukan, administrator IAM dapat membuat kebijakan IAM.
*Untuk mempelajari cara membuat kebijakan berbasis identitas IAM dengan menggunakan contoh dokumen kebijakan JSON ini, lihat [Membuat kebijakan IAM (konsol) di Panduan Pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html).*
Untuk detail tentang tindakan dan jenis sumber daya yang ditentukan oleh Lambda, termasuk format ARNs untuk setiap jenis sumber daya, lihat [Kunci tindakan, sumber daya, dan kondisi AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html) di Referensi *Otorisasi Layanan*.
**Topics**
+ [Praktik terbaik kebijakan](#security_iam_service-with-iam-policy-best-practices)
+ [Menggunakan konsol Lambda](#security_iam_id-based-policy-examples-console)
+ [Perbolehkan pengguna untuk melihat izin mereka sendiri](#security_iam_id-based-policy-examples-view-own-permissions)
## Praktik terbaik kebijakan
Kebijakan berbasis identitas menentukan apakah seseorang dapat membuat, mengakses, atau menghapus sumber daya Lambda di akun Anda. Tindakan ini membuat Akun AWS Anda dikenai biaya. Ketika Anda membuat atau mengedit kebijakan berbasis identitas, ikuti panduan dan rekomendasi ini:
+ **Mulailah dengan kebijakan AWS terkelola dan beralih ke izin hak istimewa paling sedikit — Untuk mulai memberikan izin** kepada pengguna dan beban kerja Anda, gunakan *kebijakan AWS terkelola* yang memberikan izin untuk banyak kasus penggunaan umum. Mereka tersedia di Anda Akun AWS. Kami menyarankan Anda mengurangi izin lebih lanjut dengan menentukan kebijakan yang dikelola AWS pelanggan yang khusus untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat [Kebijakan yang dikelola AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) atau [Kebijakan yang dikelola AWS untuk fungsi tugas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dalam *Panduan Pengguna IAM*.
+ **Menerapkan izin dengan hak akses paling rendah** – Ketika Anda menetapkan izin dengan kebijakan IAM, hanya berikan izin yang diperlukan untuk melakukan tugas. Anda melakukannya dengan mendefinisikan tindakan yang dapat diambil pada sumber daya tertentu dalam kondisi tertentu, yang juga dikenal sebagai *izin dengan hak akses paling rendah*. Untuk informasi selengkapnya tentang cara menggunakan IAM untuk mengajukan izin, lihat [Kebijakan dan izin dalam IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dalam *Panduan Pengguna IAM*.
+ **Gunakan kondisi dalam kebijakan IAM untuk membatasi akses lebih lanjut** – Anda dapat menambahkan suatu kondisi ke kebijakan Anda untuk membatasi akses ke tindakan dan sumber daya. Sebagai contoh, Anda dapat menulis kondisi kebijakan untuk menentukan bahwa semua permintaan harus dikirim menggunakan SSL. Anda juga dapat menggunakan ketentuan untuk memberikan akses ke tindakan layanan jika digunakan melalui yang spesifik Layanan AWS, seperti CloudFormation. Untuk informasi selengkapnya, lihat [Elemen kebijakan JSON IAM: Kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dalam *Panduan Pengguna IAM*.
+ **Gunakan IAM Access Analyzer untuk memvalidasi kebijakan IAM Anda untuk memastikan izin yang aman dan fungsional** – IAM Access Analyzer memvalidasi kebijakan baru dan yang sudah ada sehingga kebijakan tersebut mematuhi bahasa kebijakan IAM (JSON) dan praktik terbaik IAM. IAM Access Analyzer menyediakan lebih dari 100 pemeriksaan kebijakan dan rekomendasi yang dapat ditindaklanjuti untuk membantu Anda membuat kebijakan yang aman dan fungsional. Untuk informasi selengkapnya, lihat [Validasi kebijakan dengan IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dalam *Panduan Pengguna IAM*.
+ **Memerlukan otentikasi multi-faktor (MFA)** - Jika Anda memiliki skenario yang mengharuskan pengguna IAM atau pengguna root di Anda, Akun AWS aktifkan MFA untuk keamanan tambahan. Untuk meminta MFA ketika operasi API dipanggil, tambahkan kondisi MFA pada kebijakan Anda. Untuk informasi selengkapnya, lihat [Amankan akses API dengan MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dalam *Panduan Pengguna IAM*.
Untuk informasi selengkapnya tentang praktik terbaik dalam IAM, lihat [Praktik terbaik keamanan di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dalam *Panduan Pengguna IAM*.
## Menggunakan konsol Lambda
Untuk mengakses AWS Lambda konsol, Anda harus memiliki set izin minimum. Izin ini harus memungkinkan Anda untuk membuat daftar dan melihat detail tentang sumber daya Lambda di situs Anda. Akun AWS Jika Anda membuat kebijakan berbasis identitas yang lebih ketat daripada izin minimum yang diperlukan, konsol tidak akan berfungsi sebagaimana mestinya untuk entitas (pengguna atau peran) dengan kebijakan tersebut.
Anda tidak perlu mengizinkan izin konsol minimum untuk pengguna yang melakukan panggilan hanya ke AWS CLI atau AWS API. Sebagai gantinya, izinkan akses hanya ke tindakan yang sesuai dengan operasi API yang coba mereka lakukan.
Untuk contoh kebijakan yang memberikan akses minimal untuk pengembangan fungsi, lihat [Memberikan pengguna akses ke fungsi Lambda](permissions-user-function.md). Selain Lambda APIs, konsol Lambda menggunakan layanan lain untuk menampilkan konfigurasi pemicu dan memungkinkan Anda menambahkan pemicu baru. Jika pengguna Anda menggunakan Lambda dengan layanan lain, mereka juga memerlukan akses ke layanan tersebut. Untuk perincian konfigurasi layanan lain dengan Lambda, lihat [Memanggil Lambda dengan acara dari layanan lain AWS](lambda-services.md).
## Perbolehkan pengguna untuk melihat izin mereka sendiri
Contoh ini menunjukkan cara membuat kebijakan yang mengizinkan pengguna IAM melihat kebijakan inline dan terkelola yang dilampirkan ke identitas pengguna mereka. Kebijakan ini mencakup izin untuk menyelesaikan tindakan ini di konsol atau menggunakan API atau secara terprogram. AWS CLI AWS
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS kebijakan terkelola untuk AWS Lambda
Kebijakan AWS terkelola adalah kebijakan mandiri yang dibuat dan dikelola oleh AWS. AWS Kebijakan terkelola dirancang untuk memberikan izin bagi banyak kasus penggunaan umum sehingga Anda dapat mulai menetapkan izin kepada pengguna, grup, dan peran.
Perlu diingat bahwa kebijakan AWS terkelola mungkin tidak memberikan izin hak istimewa paling sedikit untuk kasus penggunaan spesifik Anda karena tersedia untuk digunakan semua pelanggan. AWS Kami menyarankan Anda untuk mengurangi izin lebih lanjut dengan menentukan [kebijakan yang dikelola pelanggan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) yang khusus untuk kasus penggunaan Anda.
Anda tidak dapat mengubah izin yang ditentukan dalam kebijakan AWS terkelola. Jika AWS memperbarui izin yang ditentukan dalam kebijakan AWS terkelola, pembaruan akan memengaruhi semua identitas utama (pengguna, grup, dan peran) yang dilampirkan kebijakan tersebut. AWS kemungkinan besar akan memperbarui kebijakan AWS terkelola saat baru Layanan AWS diluncurkan atau operasi API baru tersedia untuk layanan yang ada.
Untuk informasi selengkapnya, lihat [Kebijakan terkelola AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dalam *Panduan Pengguna IAM*.
**Topics**
+ [AWS kebijakan terkelola: AWSLambda\$1FullAccess](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess)
+ [AWS kebijakan terkelola: AWSLambda\$1ReadOnlyAccess](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess)
+ [AWS kebijakan terkelola: AWSLambda BasicExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole)
+ [AWS kebijakan terkelola: AWSLambda BasicDurableExecutionRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy)
+ [AWS kebijakan terkelola: Peran AWSLambda Dynamo DBExecution](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole)
+ [AWS kebijakan terkelola: AWSLambda ENIManagement Akses](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess)
+ [AWS kebijakan terkelola: AWSLambdaInvocation-DynamoDB](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB)
+ [AWS kebijakan terkelola: AWSLambda KinesisExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole)
+ [AWS kebijakan terkelola: AWSLambda MSKExecution Peran](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole)
+ [AWS kebijakan terkelola: AWSLambda Peran](#lambda-security-iam-awsmanpol-AWSLambdaRole)
+ [AWS kebijakan terkelola: AWSLambda SQSQueue ExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole)
+ [AWS kebijakan terkelola: AWSLambda VPCAccess ExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole)
+ [AWS kebijakan terkelola: AWSLambda Dikelola EC2 ResourceOperator](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator)
+ [AWS kebijakan terkelola: AWSLambda ServiceRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy)
+ [Lambda memperbarui kebijakan terkelola AWS](#lambda-security-iam-awsmanpol-updates)
## AWS kebijakan terkelola: AWSLambda\$1FullAccess
Kebijakan ini memberikan akses penuh ke tindakan Lambda. Ini juga memberikan izin ke AWS layanan lain yang digunakan untuk mengembangkan dan memelihara sumber daya Lambda.
Anda dapat melampirkan `AWSLambda_FullAccess` kebijakan ke pengguna, grup, dan peran Anda.
**Detail izin**
Kebijakan ini mencakup izin berikut:
+ `lambda`— Memungkinkan kepala sekolah akses penuh ke Lambda.
+ `cloudformation`— Memungkinkan kepala sekolah untuk menggambarkan AWS CloudFormation tumpukan dan daftar sumber daya di tumpukan tersebut.
+ `cloudwatch`— Memungkinkan kepala sekolah untuk mencantumkan metrik Amazon dan mendapatkan CloudWatch data metrik.
+ `ec2`— Memungkinkan kepala sekolah untuk menggambarkan kelompok keamanan, subnet, dan. VPCs
+ `iam`— Memungkinkan prinsipal untuk mendapatkan kebijakan, versi kebijakan, peran, kebijakan peran, kebijakan peran terlampir, dan daftar peran. Kebijakan ini juga memungkinkan kepala sekolah untuk meneruskan peran ke Lambda. `PassRole`Izin digunakan saat Anda menetapkan peran eksekusi ke fungsi. `CreateServiceLinkedRole`Izin digunakan saat membuat peran terkait layanan.
+ `kms`— Memungkinkan prinsipal untuk membuat daftar alias dan menjelaskan kunci untuk enkripsi volume.
+ `logs`— Memungkinkan prinsipal untuk mendeskripsikan aliran log, mendapatkan peristiwa log, memfilter peristiwa log, dan untuk memulai dan menghentikan sesi Live Tail.
+ `states`— Memungkinkan kepala sekolah untuk mendeskripsikan dan membuat daftar AWS Step Functions mesin negara.
+ `tag`— Memungkinkan prinsipal untuk mendapatkan sumber daya berdasarkan tag mereka.
+ `xray`— Memungkinkan kepala sekolah untuk mendapatkan ringkasan AWS X-Ray jejak dan mengambil daftar jejak yang ditentukan oleh ID.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)di *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda\$1ReadOnlyAccess
Kebijakan ini memberikan akses hanya-baca ke sumber daya Lambda dan AWS layanan lain yang digunakan untuk mengembangkan dan memelihara sumber daya Lambda.
Anda dapat melampirkan `AWSLambda_ReadOnlyAccess` kebijakan ke pengguna, grup, dan peran Anda.
**Detail izin**
Kebijakan ini mencakup izin berikut:
+ `lambda`— Memungkinkan kepala sekolah untuk mendapatkan dan membuat daftar semua sumber daya.
+ `cloudformation`— Memungkinkan kepala sekolah untuk mendeskripsikan dan daftar AWS CloudFormation tumpukan dan daftar sumber daya di tumpukan tersebut.
+ `cloudwatch`— Memungkinkan kepala sekolah untuk mencantumkan metrik Amazon dan mendapatkan CloudWatch data metrik.
+ `ec2`— Memungkinkan kepala sekolah untuk menggambarkan kelompok keamanan, subnet, dan. VPCs
+ `iam`— Memungkinkan prinsipal untuk mendapatkan kebijakan, versi kebijakan, peran, kebijakan peran, kebijakan peran terlampir, dan daftar peran.
+ `kms`— Memungkinkan kepala sekolah untuk daftar alias.
+ `logs`— Memungkinkan prinsipal untuk mendeskripsikan aliran log, mendapatkan peristiwa log, memfilter peristiwa log, dan untuk memulai dan menghentikan sesi Live Tail.
+ `states`— Memungkinkan kepala sekolah untuk mendeskripsikan dan membuat daftar AWS Step Functions mesin negara.
+ `tag`— Memungkinkan prinsipal untuk mendapatkan sumber daya berdasarkan tag mereka.
+ `xray`— Memungkinkan kepala sekolah untuk mendapatkan ringkasan AWS X-Ray jejak dan mengambil daftar jejak yang ditentukan oleh ID.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)di *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda BasicExecutionRole
Kebijakan ini memberikan izin untuk mengunggah log ke CloudWatch Log.
Anda dapat melampirkan `AWSLambdaBasicExecutionRole` kebijakan ke pengguna, grup, dan peran Anda.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)di *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda BasicDurableExecutionRolePolicy
Kebijakan ini memberikan izin menulis ke CloudWatch Log dan read/write izin untuk eksekusi tahan lama yang APIs digunakan oleh fungsi tahan lama Lambda. Kebijakan ini memberikan izin penting yang diperlukan untuk fungsi tahan lama Lambda, yang menggunakan APIs eksekusi tahan lama untuk mempertahankan kemajuan dan mempertahankan status di seluruh pemanggilan fungsi.
Anda dapat melampirkan `AWSLambdaBasicDurableExecutionRolePolicy` kebijakan ke pengguna, grup, dan peran Anda.
**Detail izin**
Kebijakan ini mencakup izin berikut:
+ `logs`— Memungkinkan prinsipal untuk membuat grup log dan aliran log, dan menulis peristiwa log ke Log. CloudWatch
+ `lambda`- Memungkinkan kepala sekolah untuk memeriksa status eksekusi yang tahan lama dan mengambil status eksekusi yang tahan lama untuk fungsi Lambda yang tahan lama.
Untuk melihat detail selengkapnya tentang kebijakan, termasuk versi terbaru dari dokumen kebijakan JSON, lihat [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)di *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: Peran AWSLambda Dynamo DBExecution
Kebijakan ini memberikan izin untuk membaca catatan dari aliran Amazon DynamoDB dan menulis ke Log. CloudWatch
Anda dapat melampirkan `AWSLambdaDynamoDBExecutionRole` kebijakan ke pengguna, grup, dan peran Anda.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [DBExecutionPeran AWSLambda Dynamo](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) dalam Panduan *Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda ENIManagement Akses
Kebijakan ini memberikan izin untuk membuat, mendeskripsikan, dan menghapus antarmuka jaringan elastis yang digunakan oleh fungsi Lambda berkemampuan VPC.
Anda dapat melampirkan `AWSLambdaENIManagementAccess` kebijakan ke pengguna, grup, dan peran Anda.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambdaENIManagementAkses](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html) di *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambdaInvocation-DynamoDB
Kebijakan ini memberikan akses baca ke Amazon DynamoDB Streams.
Anda dapat melampirkan `AWSLambdaInvocation-DynamoDB` kebijakan ke pengguna, grup, dan peran Anda.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html)di *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda KinesisExecutionRole
Kebijakan ini memberikan izin untuk membaca peristiwa dari aliran data Amazon Kinesis dan menulis ke Log. CloudWatch
Anda dapat melampirkan `AWSLambdaKinesisExecutionRole` kebijakan ke pengguna, grup, dan peran Anda.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)di *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda MSKExecution Peran
Kebijakan ini memberikan izin untuk membaca dan mengakses catatan dari klaster Amazon Managed Streaming for Apache Kafka, mengelola antarmuka jaringan elastis, dan menulis ke Log. CloudWatch
Anda dapat melampirkan `AWSLambdaMSKExecutionRole` kebijakan ke pengguna, grup, dan peran Anda.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambdaMSKExecutionPeran](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) dalam *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda Peran
Kebijakan ini memberikan izin untuk menjalankan fungsi Lambda.
Anda dapat melampirkan `AWSLambdaRole` kebijakan ke pengguna, grup, dan peran Anda.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambdaPeran](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) dalam *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda SQSQueue ExecutionRole
Kebijakan ini memberikan izin untuk membaca dan menghapus pesan dari antrian Layanan Antrian Sederhana Amazon, dan memberikan izin menulis ke Log. CloudWatch
Anda dapat melampirkan `AWSLambdaSQSQueueExecutionRole` kebijakan ke pengguna, grup, dan peran Anda.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)di *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda VPCAccess ExecutionRole
Kebijakan ini memberikan izin untuk mengelola antarmuka jaringan elastis dalam Amazon Virtual Private Cloud dan menulis ke Log. CloudWatch
Anda dapat melampirkan `AWSLambdaVPCAccessExecutionRole` kebijakan ke pengguna, grup, dan peran Anda.
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)di *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda Dikelola EC2 ResourceOperator
Kebijakan ini memungkinkan pengelolaan instans Amazon Elastic Compute Cloud otomatis untuk penyedia kapasitas Lambda. Ini memberikan izin ke layanan scaler Lambda untuk melakukan operasi siklus hidup instance atas nama Anda.
Anda dapat melampirkan `AWSLambdaManagedEC2ResourceOperator` kebijakan ke pengguna, grup, dan peran Anda.
**Detail izin**
Kebijakan ini mencakup izin berikut:
+ `ec2:RunInstances`— Memungkinkan Lambda meluncurkan instans Amazon EC2 baru dengan syarat ec2: ManagedResourceOperator sama dengan scaler.lambda.amazonaws.com dan membatasi penggunaan AMI hanya untuk gambar milik Amazon.
+ `ec2:DescribeInstances`dan `ec2:DescribeInstanceStatus` — Memungkinkan Lambda untuk memantau status instance dan mengambil informasi instance.
+ `ec2:CreateTags`— Memungkinkan Lambda menandai sumber daya Amazon EC2 untuk tujuan manajemen dan identifikasi.
+ `ec2:DescribeAvailabilityZones`— Memungkinkan Lambda untuk melihat zona yang tersedia misalnya keputusan penempatan.
+ `ec2:DescribeCapacityReservations`— Memungkinkan Lambda untuk memeriksa reservasi kapasitas untuk penempatan instans yang optimal.
+ `ec2:DescribeInstanceTypes`dan `ec2:DescribeInstanceTypeOfferings` — Memungkinkan Lambda untuk meninjau jenis instans yang tersedia dan penawarannya.
+ `ec2:DescribeSubnets`— Memungkinkan Lambda untuk memeriksa konfigurasi subnet untuk perencanaan jaringan.
+ `ec2:DescribeSecurityGroups`— Memungkinkan Lambda untuk mengambil informasi grup keamanan untuk konfigurasi antarmuka jaringan.
+ `ec2:CreateNetworkInterface`— Memungkinkan Lambda untuk membuat antarmuka jaringan dan mengelola subnet dan asosiasi grup keamanan.
+ `ec2:AttachNetworkInterface`[— Memungkinkan Lambda melampirkan antarmuka jaringan ke instans Amazon EC2 dengan kondisi yang sama dengan scaler.lambda.amazonaws.com. `ec2:ManagedResourceOperator`](http://scaler.lambda.amazonaws.com/)
Untuk informasi selengkapnya tentang kebijakan ini, termasuk dokumen kebijakan JSON dan versi kebijakan, lihat [AWSLambdaDikelola EC2 ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) dalam *Panduan Referensi Kebijakan AWS Terkelola*.
## AWS kebijakan terkelola: AWSLambda ServiceRolePolicy
Kebijakan ini dilampirkan pada peran terkait layanan yang diberi nama AWSService RoleForLambda untuk memungkinkan Lambda menghentikan instans yang dikelola sebagai bagian dari penyedia kapasitas Lambda.
**Detail izin**
Kebijakan ini mencakup izin berikut:
+ `ec2:TerminateInstances`— Memungkinkan Lambda untuk menghentikan instans EC2 dengan kondisi bahwa ec2: sama dengan scaler.lambda.amazonaws.com. ManagedResourceOperator
+ `ec2:DescribeInstanceStatus`dan `ec2:DescribeInstances` — Memungkinkan Lambda untuk menggambarkan instans EC2.
Untuk informasi selengkapnya tentang kebijakan ini, lihat [Menggunakan peran terkait layanan untuk Lambda](using-service-linked-roles.md).
## Lambda memperbarui kebijakan terkelola AWS
| Ubah | Deskripsi | Date |
| --- | --- | --- |
| [AWSLambdaDikelola EC2 ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) - Kebijakan baru | Lambda menambahkan kebijakan terkelola baru untuk mengaktifkan manajemen instans Amazon EC2 otomatis untuk penyedia kapasitas Lambda, yang memungkinkan layanan scaler melakukan operasi siklus hidup instans. | November 30, 2025 |
| [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html) – Kebijakan baru | Lambda menambahkan kebijakan terkelola baru untuk peran terkait layanan guna memungkinkan Lambda menghentikan instans yang dikelola sebagai bagian dari penyedia kapasitas Lambda. | November 30, 2025 |
| [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Ubah | Lambda memperbarui `AWSLambda_FullAccess` kebijakan untuk mengizinkan `kms:DescribeKey` dan `iam:CreateServiceLinkedRole` tindakan. | November 30, 2025 |
| [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)— Kebijakan terkelola baru | Lambda merilis kebijakan terkelola baru `AWSLambdaBasicDurableExecutionRolePolicy` yang menyediakan izin menulis ke CloudWatch Log dan read/write izin untuk eksekusi tahan lama yang digunakan APIs oleh fungsi tahan lama Lambda. | Desember 1, 2025 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)dan [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Perubahan | Lambda memperbarui `AWSLambda_FullAccess` kebijakan `AWSLambda_ReadOnlyAccess` dan untuk mengizinkan `logs:StartLiveTail` dan `logs:StopLiveTail` tindakan. | Maret 17, 2025 |
| [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)— Ubah | Lambda memperbarui `AWSLambdaVPCAccessExecutionRole` kebijakan untuk mengizinkan tindakan. `ec2:DescribeSubnets` | Januari 5, 2024 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)— Ubah | Lambda memperbarui `AWSLambda_ReadOnlyAccess` kebijakan untuk mengizinkan prinsipal membuat daftar tumpukan. CloudFormation | Juli 27, 2023 |
| AWS Lambda mulai melacak perubahan | AWS Lambda mulai melacak perubahan untuk kebijakan yang AWS dikelola. | Juli 27, 2023 |
# Memecahkan masalah AWS Lambda identitas dan akses
Gunakan informasi berikut untuk membantu Anda mendiagnosis dan memperbaiki masalah umum yang mungkin Anda temukan saat bekerja dengan Lambda dan IAM.
**Topics**
+ [Saya tidak diotorisasi untuk melakukan tindakan di Lambda](#security_iam_troubleshoot-no-permissions)
+ [Saya tidak berwenang untuk melakukan iam: PassRole](#security_iam_troubleshoot-passrole)
+ [Saya ingin mengizinkan orang-orang di luar saya Akun AWS untuk mengakses sumber daya Lambda saya](#security_iam_troubleshoot-cross-account-access)
## Saya tidak diotorisasi untuk melakukan tindakan di Lambda
Jika Anda menerima pesan kesalahan bahwa Anda tidak memiliki otorisasi untuk melakukan tindakan, kebijakan Anda harus diperbarui agar Anda dapat melakukan tindakan tersebut.
Contoh kesalahan berikut terjadi ketika pengguna IAM `mateojackson` mencoba menggunakan konsol untuk melihat detail tentang suatu sumber daya `my-example-widget` rekaan, tetapi tidak memiliki izin `lambda:GetWidget` rekaan.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget
```
Dalam hal ini, kebijakan untuk pengguna `mateojackson` harus diperbarui untuk mengizinkan akses ke sumber daya `my-example-widget` dengan menggunakan tindakan `lambda:GetWidget`.
Jika Anda memerlukan bantuan, hubungi AWS administrator Anda. Administrator Anda adalah orang yang memberi Anda kredensial masuk.
## Saya tidak berwenang untuk melakukan iam: PassRole
Jika Anda menerima kesalahan bahwa Anda tidak diizinkan untuk melakukan `iam:PassRole` tindakan, kebijakan Anda harus diperbarui agar Anda dapat meneruskan peran ke Lambda.
Beberapa Layanan AWS memungkinkan Anda untuk meneruskan peran yang ada ke layanan tersebut alih-alih membuat peran layanan baru atau peran terkait layanan. Untuk melakukannya, Anda harus memiliki izin untuk meneruskan peran ke layanan.
Contoh kesalahan berikut terjadi saat pengguna IAM bernama `marymajor` mencoba menggunakan konsol untuk melakukan tindakan di Lambda. Namun, tindakan tersebut memerlukan layanan untuk mendapatkan izin yang diberikan oleh peran layanan. Mary tidak memiliki izin untuk meneruskan peran tersebut pada layanan.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dalam kasus ini, kebijakan Mary harus diperbarui agar dia mendapatkan izin untuk melakukan tindakan `iam:PassRole` tersebut.
Jika Anda memerlukan bantuan, hubungi AWS administrator Anda. Administrator Anda adalah orang yang memberi Anda kredensial masuk.
## Saya ingin mengizinkan orang-orang di luar saya Akun AWS untuk mengakses sumber daya Lambda saya
Anda dapat membuat peran yang dapat digunakan pengguna di akun lain atau orang-orang di luar organisasi Anda untuk mengakses sumber daya Anda. Anda dapat menentukan siapa saja yang dipercaya untuk mengambil peran tersebut. Untuk layanan yang mendukung kebijakan berbasis sumber daya atau daftar kontrol akses (ACLs), Anda dapat menggunakan kebijakan tersebut untuk memberi orang akses ke sumber daya Anda.
Untuk mempelajari selengkapnya, periksa referensi berikut:
+ Untuk mempelajari apakah Lambda mendukung fitur-fitur ini, lihat [Bagaimana AWS Lambda bekerja dengan IAM](security_iam_service-with-iam.md).
+ Untuk mempelajari cara menyediakan akses ke sumber daya Anda di seluruh sumber daya Akun AWS yang Anda miliki, lihat [Menyediakan akses ke pengguna IAM di pengguna lain Akun AWS yang Anda miliki](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) di *Panduan Pengguna IAM*.
+ Untuk mempelajari cara menyediakan akses ke sumber daya Anda kepada pihak ketiga Akun AWS, lihat [Menyediakan akses yang Akun AWS dimiliki oleh pihak ketiga](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dalam *Panduan Pengguna IAM*.
+ Untuk mempelajari cara memberikan akses melalui federasi identitas, lihat [Menyediakan akses ke pengguna terautentikasi eksternal (federasi identitas)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dalam *Panduan Pengguna IAM*.
+ *Untuk mempelajari perbedaan antara menggunakan peran dan kebijakan berbasis sumber daya untuk akses lintas akun, lihat [Akses sumber daya lintas akun di IAM di Panduan Pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html).*
# Buat strategi tata kelola untuk fungsi dan lapisan Lambda
Untuk membangun dan menerapkan aplikasi cloud-native tanpa server, Anda harus mengizinkan kelincahan dan kecepatan ke pasar dengan tata kelola dan pagar pembatas yang sesuai. Anda menetapkan prioritas tingkat bisnis, mungkin menekankan kelincahan sebagai prioritas utama, atau sebagai alternatif menekankan penghindaran risiko melalui tata kelola, pagar pembatas, dan kontrol. Secara realistis, Anda tidak akan memiliki strategi “salah satu/atau” tetapi strategi “dan” yang menyeimbangkan kelincahan dan pagar pembatas dalam siklus hidup pengembangan perangkat lunak Anda. Di mana pun persyaratan ini termasuk dalam siklus hidup perusahaan Anda, kemampuan tata kelola cenderung menjadi persyaratan implementasi dalam proses dan rantai alat Anda.
Berikut adalah beberapa contoh kontrol tata kelola yang mungkin diterapkan organisasi untuk Lambda:
+ Fungsi Lambda tidak boleh diakses publik.
+ Fungsi Lambda harus dilampirkan ke VPC.
+ Fungsi Lambda tidak boleh menggunakan runtime yang tidak digunakan lagi.
+ Fungsi Lambda harus ditandai dengan satu set tag yang diperlukan.
+ Lapisan Lambda tidak boleh diakses di luar organisasi.
+ Fungsi Lambda dengan grup keamanan terlampir harus memiliki tag yang cocok antara fungsi dan grup keamanan.
+ Fungsi Lambda dengan lapisan terlampir harus menggunakan versi yang disetujui
+ Variabel lingkungan Lambda harus dienkripsi saat istirahat dengan kunci yang dikelola pelanggan.
Diagram berikut adalah contoh strategi tata kelola mendalam yang mengimplementasikan kontrol dan kebijakan di seluruh proses pengembangan dan penyebaran perangkat lunak:
![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-concepts.png)
Topik berikut menjelaskan cara menerapkan kontrol untuk mengembangkan dan menerapkan fungsi Lambda di organisasi Anda, baik untuk startup maupun perusahaan. Organisasi Anda mungkin sudah memiliki alat di tempat. Topik berikut mengambil pendekatan modular untuk kontrol ini, sehingga Anda dapat memilih dan memilih komponen yang benar-benar Anda butuhkan.
**Topics**
+ [Kontrol proaktif untuk Lambda dengan AWS CloudFormation Guard](governance-cloudformation-guard.md)
+ [Menerapkan kontrol pencegahan untuk Lambda dengan AWS Config](governance-config.md)
+ [Mendeteksi penerapan dan konfigurasi Lambda yang tidak sesuai dengan AWS Config](governance-config-detection.md)
+ [Penandatanganan kode Lambda dengan AWS Signer](governance-code-signing.md)
+ [Otomatiskan penilaian keamanan untuk Lambda dengan Amazon Inspector](governance-code-scanning.md)
+ [Menerapkan observabilitas untuk keamanan dan kepatuhan Lambda](governance-observability.md)
# Kontrol proaktif untuk Lambda dengan AWS CloudFormation Guard
[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)adalah alat evaluasi open-source, tujuan umum, dan evaluasi. policy-as-code Ini dapat digunakan untuk tata kelola preventif dan kepatuhan dengan memvalidasi template Infrastructure as Code (IAc) dan komposisi layanan terhadap aturan kebijakan. Aturan-aturan ini dapat disesuaikan berdasarkan persyaratan tim atau organisasi Anda. Untuk fungsi Lambda, aturan Penjaga dapat digunakan untuk mengontrol pembuatan sumber daya dan pembaruan konfigurasi dengan menentukan pengaturan properti yang diperlukan saat membuat atau memperbarui fungsi Lambda.
Administrator kepatuhan menentukan daftar kontrol dan kebijakan tata kelola yang diperlukan untuk menerapkan dan memperbarui fungsi Lambda. Administrator platform mengimplementasikan kontrol dalam CI/CD pipelines, as pre-commit validation webhooks with code repositories, and provide developers with command line tools for validating templates and code on local workstations. Developers author code, validate templates with command line tools, and then commit code to repositories, which are then automatically validated via the CI/CD pipeline sebelum penyebaran ke lingkungan. AWS
Guard memungkinkan Anda untuk [menulis aturan](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html) dan menerapkan kontrol Anda dengan bahasa khusus domain sebagai berikut.
![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-cloudformation-guard.png)
Misalnya, Anda ingin memastikan bahwa pengembang hanya memilih runtime terbaru. Anda dapat menentukan dua kebijakan berbeda, satu untuk mengidentifikasi [runtime](lambda-runtimes.md) yang sudah tidak digunakan lagi dan yang lain untuk mengidentifikasi runtime yang akan segera usang. Untuk melakukan ini, Anda dapat menulis `etc/rules.guard` file berikut:
```
let lambda_functions = Resources.*[
Type == "AWS::Lambda::Function"
]
rule lambda_already_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <>
}
}
}
}
rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <>
}
}
}
}
```
Sekarang misalkan Anda menulis `iac/lambda.yaml` CloudFormation template berikut yang mendefinisikan fungsi Lambda:
```
Fn:
Type: AWS::Lambda::Function
Properties:
Runtime: python3.7
CodeUri: src
Handler: fn.handler
Role: !GetAtt FnRole.Arn
Layers:
- arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35
```
Setelah [menginstal](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html) utilitas Guard, validasi template Anda:
```
cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml
```
Keluaran terlihat seperti ini:
```
lambda.yaml Status = FAIL
FAILED rules
rules.guard/lambda_soon_to_be_deprecated_runtime
---
Evaluating data lambda.yaml against rules rules.guard
Number of non-compliant resources 1
Resource = Fn {
Type = AWS::Lambda::Function
Rule = lambda_soon_to_be_deprecated_runtime {
ALL {
Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] {
ComparisonError {
Message = Lambda function is using a runtime that is targeted for deprecation.
Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])]
}
PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15]
Operator = NOT IN
Value = "python3.7"
ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]]
Code:
86. Fn:
87. Type: AWS::Lambda::Function
88. Properties:
89. Runtime: python3.7
90. CodeUri: src
91. Handler: fn.handler
}
}
}
}
```
Guard memungkinkan pengembang Anda untuk melihat dari workstation pengembang lokal mereka bahwa mereka perlu memperbarui template untuk menggunakan runtime yang diizinkan oleh organisasi. Ini terjadi sebelum melakukan repositori kode dan kemudian gagal memeriksa dalam CI/CD pipeline. As a result, your developers get this feedback on how to develop compliant templates and shift their time to writing code that delivers business value. This control can be applied on the local developer workstation, in a pre-commit validation webhook, and/or in the CI/CD pipeline sebelum penerapan.
## Peringatan
Jika Anda menggunakan AWS Serverless Application Model (AWS SAM) template untuk menentukan fungsi Lambda, ketahuilah bahwa Anda perlu memperbarui aturan Guard untuk mencari jenis `AWS::Serverless::Function` sumber daya sebagai berikut.
```
let lambda_functions = Resources.*[
Type == "AWS::Serverless::Function"
]
```
Guard juga mengharapkan properti untuk dimasukkan dalam definisi sumber daya. Sementara itu, AWS SAM template memungkinkan properti yang akan ditentukan di bagian [Globals](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) terpisah. Properti yang didefinisikan di bagian Globals tidak divalidasi dengan aturan Penjaga Anda.
Seperti yang diuraikan dalam [dokumentasi](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html) pemecahan masalah Guard, ketahuilah bahwa Guard tidak mendukung intrinsik bentuk pendek seperti `!GetAtt` atau `!Sub` dan sebagai gantinya memerlukan penggunaan formulir yang diperluas: and. `Fn::GetAtt` `Fn::Sub` ([Contoh sebelumnya](#guard-iac-yaml) tidak mengevaluasi properti Peran, jadi intrinsik bentuk pendek digunakan untuk kesederhanaan.)
# Menerapkan kontrol pencegahan untuk Lambda dengan AWS Config
Sangat penting untuk memastikan kepatuhan dalam aplikasi tanpa server Anda sedini mungkin dalam proses pengembangan. Dalam topik ini, kami membahas cara menerapkan kontrol pencegahan menggunakan. [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) Ini memungkinkan Anda untuk menerapkan pemeriksaan kepatuhan lebih awal dalam proses pengembangan dan memungkinkan Anda untuk menerapkan kontrol yang sama di CI/CD saluran pipa Anda. Ini juga menstandarisasi kontrol Anda dalam repositori aturan yang dikelola secara terpusat sehingga Anda dapat menerapkan kontrol secara konsisten di seluruh akun Anda. AWS
Misalnya, administrator kepatuhan Anda menetapkan persyaratan untuk memastikan bahwa semua fungsi AWS X-Ray Lambda menyertakan penelusuran. Dengan AWS Config mode proaktif, Anda dapat menjalankan pemeriksaan kepatuhan pada sumber daya fungsi Lambda Anda sebelum penerapan, mengurangi risiko penerapan fungsi Lambda yang dikonfigurasi secara tidak benar dan menghemat waktu pengembang dengan memberi mereka umpan balik yang lebih cepat pada infrastruktur sebagai templat kode. Berikut ini adalah visualisasi aliran untuk kontrol pencegahan dengan: AWS Config
![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-config-1.png)
Pertimbangkan persyaratan bahwa semua fungsi Lambda harus mengaktifkan penelusuran. Sebagai tanggapan, tim platform mengidentifikasi perlunya AWS Config aturan tertentu untuk berjalan secara proaktif di semua akun. Aturan ini menandai fungsi Lambda apa pun yang tidak memiliki konfigurasi penelusuran X-Ray yang dikonfigurasi sebagai sumber daya yang tidak sesuai. Tim mengembangkan aturan, mengemasnya dalam paket [kesesuaian, dan menyebarkan paket](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html) kesesuaian di semua AWS akun untuk memastikan bahwa semua akun dalam organisasi menerapkan kontrol ini secara seragam. Anda dapat menulis aturan dalam sintaks AWS CloudFormation Guard 2.xx, yang mengambil bentuk berikut:
```
rule name when condition { assertion }
```
Berikut ini adalah contoh aturan Penjaga yang memeriksa untuk memastikan fungsi Lambda mengaktifkan penelusuran:
```
rule lambda_tracing_check {
when configuration.tracingConfig exists {
configuration.tracingConfig.mode == "Active"
}
}
```
[Tim platform mengambil tindakan lebih lanjut dengan mewajibkan bahwa setiap AWS CloudFormation penerapan memanggil kait pra-buat/pembaruan.](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html) Mereka memikul tanggung jawab penuh untuk mengembangkan hook ini dan mengonfigurasi pipeline, memperkuat kontrol terpusat atas aturan kepatuhan dan mempertahankan aplikasi mereka yang konsisten di semua penerapan. Untuk mengembangkan, mengemas, dan mendaftarkan hook, lihat [Mengembangkan AWS CloudFormation Hooks](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html) dalam dokumentasi CloudFormation Command Line Interface (CFN-CLI). Anda dapat menggunakan [CloudFormation CLI](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) untuk membuat proyek hook:
```
cfn init
```
Perintah ini meminta Anda untuk beberapa informasi dasar tentang proyek hook Anda dan membuat proyek dengan file berikut di dalamnya:
```
README.md
.json
rpdk.log
src/handler.py
template.yml
hook-role.yaml
```
Sebagai pengembang hook, Anda perlu menambahkan jenis sumber daya target yang diinginkan dalam file `.json` konfigurasi. Dalam konfigurasi di bawah ini, hook dikonfigurasi untuk mengeksekusi sebelum fungsi Lambda dibuat menggunakan. CloudFormation Anda dapat menambahkan penangan serupa untuk `preUpdate` dan `preDelete` tindakan juga.
```
"handlers": {
"preCreate": {
"targetNames": [
"AWS::Lambda::Function"
],
"permissions": []
}
}
```
Anda juga perlu memastikan bahwa CloudFormation hook memiliki izin yang sesuai untuk memanggil. AWS Config APIs Anda dapat melakukannya dengan memperbarui file definisi peran bernama`hook-role.yaml`. File definisi peran memiliki kebijakan kepercayaan berikut secara default, yang memungkinkan CloudFormation untuk mengambil peran.
```
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- hooks.cloudformation.amazonaws.com
- resources.cloudformation.amazonaws.com
```
Untuk mengizinkan hook ini memanggil config APIs, Anda harus menambahkan izin berikut ke pernyataan Policy. Kemudian Anda mengirimkan proyek hook menggunakan `cfn submit` perintah, di mana CloudFormation menciptakan peran untuk Anda dengan izin yang diperlukan.
```
Policies:
- PolicyName: HookTypePolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- "config:Describe*"
- "config:Get*"
- "config:List*"
- "config:SelectResourceConfig"
Resource: "*
```
Selanjutnya, Anda perlu menulis fungsi Lambda dalam file. `src/handler.py` Dalam file ini, Anda menemukan metode bernama `preCreate``preUpdate`,, dan `preDelete` sudah dibuat ketika Anda memulai proyek. Anda bertujuan untuk menulis fungsi umum yang dapat digunakan kembali yang memanggil AWS Config `StartResourceEvaluation` API dalam mode proaktif menggunakan. AWS SDK untuk Python (Boto3) Panggilan API ini mengambil properti sumber daya sebagai input dan mengevaluasi sumber daya terhadap definisi aturan.
```
def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent:
LOG.info("Fetching proactive data")
config_client = boto3.client('config')
resource_specs = {
'ResourceId': 'MyFunction',
'ResourceType': resource_type,
'ResourceConfiguration': json.dumps(function_properties),
'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA'
}
LOG.info("Resource Specifications:", resource_specs)
eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60)
ResourceEvaluationId = eval_response.ResourceEvaluationId
compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId)
LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType)
if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType:
return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant)
else:
return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.")
```
Sekarang Anda dapat memanggil fungsi umum dari handler untuk hook pra-buat. Berikut adalah contoh handler:
```
@hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION)
def pre_create_handler(
session: Optional[SessionProxy],
request: HookHandlerRequest,
callback_context: MutableMapping[str, Any],
type_configuration: TypeConfigurationModel
) -> ProgressEvent:
LOG.info("Starting execution of the hook")
target_name = request.hookContext.targetName
LOG.info("Target Name:", target_name)
if "AWS::Lambda::Function" == target_name:
return validate_lambda_tracing_config(target_name,
request.hookContext.targetModel.get("resourceProperties")
)
else:
raise exceptions.InvalidRequest(f"Unknown target type: {target_name}")
```
Setelah langkah ini Anda dapat mendaftarkan hook dan mengkonfigurasinya untuk mendengarkan semua acara pembuatan AWS Lambda fungsi.
Pengembang menyiapkan template infrastruktur sebagai kode (IAc) untuk layanan mikro tanpa server menggunakan Lambda. Persiapan ini mencakup kepatuhan terhadap standar internal, diikuti dengan pengujian lokal dan melakukan template ke repositori. Berikut adalah contoh template IAc:
```
MyLambdaFunction:
Type: 'AWS::Lambda::Function'
Properties:
Handler: index.handler
Role: !GetAtt LambdaExecutionRole.Arn
FunctionName: MyLambdaFunction
Code:
ZipFile: |
import json
def handler(event, context):
return {
'statusCode': 200,
'body': json.dumps('Hello World!')
}
Runtime: python3.14
TracingConfig:
Mode: PassThrough
MemorySize: 256
Timeout: 10
```
Sebagai bagian dari CI/CD proses, ketika CloudFormation template diterapkan, CloudFormation layanan memanggil kait pra-buat/pembaruan tepat sebelum menyediakan jenis sumber daya. `AWS::Lambda::Function` Hook menggunakan AWS Config aturan yang berjalan dalam mode proaktif untuk memverifikasi bahwa konfigurasi fungsi Lambda menyertakan konfigurasi penelusuran yang diamanatkan. Respons dari hook menentukan langkah selanjutnya. Jika sesuai, hook menandakan keberhasilan, dan CloudFormation melanjutkan untuk menyediakan sumber daya. Jika tidak, penyebaran CloudFormation tumpukan gagal, pipeline segera berhenti, dan sistem mencatat detail untuk peninjauan berikutnya. Pemberitahuan kepatuhan dikirim ke pemangku kepentingan terkait.
Anda dapat menemukan success/fail informasi kait di CloudFormation konsol:
![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-config-2.png)
Jika Anda mengaktifkan log untuk CloudFormation hook Anda, Anda dapat menangkap hasil evaluasi hook. Berikut adalah contoh log untuk hook dengan status gagal, yang menunjukkan bahwa fungsi Lambda tidak mengaktifkan X-Ray:
![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-config-3.png)
Jika pengembang memilih untuk mengubah IAc untuk memperbarui `TracingConfig Mode` nilai dan menerapkan kembali, hook berhasil dijalankan `Active` dan tumpukan dilanjutkan dengan membuat sumber daya Lambda.
![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-config-4.png)
Dengan cara ini, Anda dapat menerapkan kontrol pencegahan dengan AWS Config dalam mode proaktif saat mengembangkan dan menerapkan sumber daya tanpa server di akun Anda. AWS Dengan mengintegrasikan AWS Config aturan ke dalam CI/CD pipeline, Anda dapat mengidentifikasi dan secara opsional memblokir penerapan sumber daya yang tidak sesuai, seperti fungsi Lambda yang tidak memiliki konfigurasi penelusuran aktif. Ini memastikan bahwa hanya sumber daya yang mematuhi kebijakan tata kelola terbaru yang diterapkan ke lingkungan Anda AWS .
# Mendeteksi penerapan dan konfigurasi Lambda yang tidak sesuai dengan AWS Config
Selain [evaluasi proaktif](governance-config.md), juga AWS Config dapat secara reaktif mendeteksi penyebaran sumber daya dan konfigurasi yang tidak sesuai dengan kebijakan tata kelola Anda. Ini penting karena kebijakan tata kelola berkembang saat organisasi Anda belajar dan menerapkan praktik terbaik baru.
Pertimbangkan skenario di mana Anda menetapkan kebijakan baru saat menerapkan atau memperbarui fungsi Lambda: Semua fungsi Lambda harus selalu menggunakan versi lapisan Lambda tertentu yang disetujui. Anda dapat mengonfigurasi AWS Config untuk memantau fungsi baru atau yang diperbarui untuk konfigurasi lapisan. Jika AWS Config mendeteksi fungsi yang tidak menggunakan versi lapisan yang disetujui, ia menandai fungsi tersebut sebagai sumber daya yang tidak sesuai. Anda dapat mengonfigurasi secara opsional AWS Config untuk memulihkan sumber daya secara otomatis dengan menentukan tindakan remediasi menggunakan dokumen otomatisasi. AWS Systems Manager Misalnya, Anda dapat menulis dokumen otomatisasi dengan Python menggunakan AWS SDK untuk Python (Boto3), yang memperbarui fungsi yang tidak sesuai untuk menunjuk ke versi lapisan yang disetujui. Dengan demikian, AWS Config berfungsi sebagai kontrol detektif dan korektif, mengotomatiskan manajemen kepatuhan.
Mari kita uraikan proses ini menjadi tiga fase implementasi penting:
![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-config-detective-1.png)
## Fase 1: Identifikasi sumber daya akses
Mulailah dengan mengaktifkan AWS Config di seluruh akun Anda dan mengonfigurasinya untuk merekam fungsi Lambda AWS . Ini memungkinkan AWS Config untuk mengamati kapan fungsi Lambda dibuat atau diperbarui. Anda kemudian dapat mengonfigurasi [aturan kebijakan khusus](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html) untuk memeriksa pelanggaran kebijakan tertentu, yang menggunakan AWS CloudFormation Guard sintaks. Aturan penjaga mengambil bentuk umum berikut:
```
rule name when condition { assertion }
```
Di bawah ini adalah contoh aturan yang memeriksa untuk memastikan bahwa lapisan tidak diatur ke versi lapisan lama:
```
rule desiredlayer when configuration.layers !empty {
some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn
}
```
Mari kita pahami sintaks aturan dan struktur:
+ **Nama aturan:** Nama aturan dalam contoh yang diberikan adalah`desiredlayer`.
+ **Kondisi:** Klausul ini menentukan kondisi di mana aturan harus diperiksa. Dalam contoh yang diberikan, kondisinya adalah`configuration.layers !empty`. Ini berarti sumber daya harus dievaluasi hanya ketika `layers` properti dalam konfigurasi tidak kosong.
+ **Pernyataan:** Setelah `when` klausa, pernyataan menentukan apa yang diperiksa aturan. Pernyataan `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` memeriksa apakah salah satu lapisan Lambda ARNs tidak cocok dengan nilainya. `OldLayerArn` Jika mereka tidak cocok, pernyataan itu benar dan aturan berlalu; jika tidak, itu gagal.
`CONFIG_RULE_PARAMETERS`adalah seperangkat parameter khusus yang dikonfigurasi dengan AWS Config aturan. Dalam hal ini, `OldLayerArn` adalah parameter di dalamnya`CONFIG_RULE_PARAMETERS`. Ini memungkinkan pengguna untuk memberikan nilai ARN tertentu yang mereka anggap lama atau tidak digunakan lagi, dan kemudian aturan memeriksa apakah ada fungsi Lambda yang menggunakan ARN lama ini.
## Tahap 2: Visualisasikan dan desain
AWS Config mengumpulkan data konfigurasi dan menyimpan data tersebut di bucket Amazon Simple Storage Service (Amazon S3). Anda dapat menggunakan [Amazon Athena](https://aws.amazon.com/athena/) untuk menanyakan data ini langsung dari bucket S3 Anda. Dengan Athena, Anda dapat menggabungkan data ini di tingkat organisasi, menghasilkan tampilan holistik dari konfigurasi sumber daya Anda di semua akun Anda. Untuk mengatur agregasi data konfigurasi sumber daya, lihat [Memvisualisasikan AWS Config data menggunakan Athena dan Amazon](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) Quick di blog Operasi dan AWS Manajemen Cloud.
Berikut ini adalah contoh query Athena untuk mengidentifikasi semua fungsi Lambda menggunakan ARN lapisan tertentu:
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.version') AS version
FROM
unnested
WHERE
lambda_configuration LIKE '%arn:aws:lambda:us-east-1:111122223333:layer:AnyGovernanceLayer:24%'
```
Berikut adalah hasil dari kueri:
![\[Query results in Athena console.\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-config-detective-2.png)
Dengan AWS Config data yang dikumpulkan di seluruh organisasi, Anda dapat membuat dasbor menggunakan [Amazon Quick](https://aws.amazon.com/quicksight/). Dengan mengimpor hasil Athena Anda ke Quick, Anda dapat memvisualisasikan seberapa baik fungsi Lambda Anda mematuhi aturan versi layer. [Dasbor ini dapat menyoroti sumber daya yang sesuai dan tidak sesuai, yang membantu Anda menentukan kebijakan penegakan hukum Anda, sebagaimana diuraikan di bagian berikutnya.](#governance-config-detective-implement) Gambar berikut adalah contoh dasbor yang melaporkan distribusi versi lapisan yang diterapkan pada fungsi dalam organisasi.
![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-config-detective-3.png)
## Tahap 3: Menerapkan dan menegakkan
Anda sekarang dapat secara opsional memasangkan aturan versi lapisan yang Anda buat di [fase 1](#governance-config-detective-identify) dengan tindakan remediasi melalui dokumen otomatisasi Systems Manager, yang Anda buat sebagai skrip Python yang ditulis dengan. AWS SDK untuk Python (Boto3) Skrip memanggil tindakan [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)API untuk setiap fungsi Lambda, memperbarui konfigurasi fungsi dengan lapisan baru ARN. Atau, Anda dapat meminta skrip mengirimkan permintaan tarik ke repositori kode untuk memperbarui lapisan ARN. Dengan cara ini penerapan kode future juga diperbarui dengan ARN lapisan yang benar.
# Penandatanganan kode Lambda dengan AWS Signer
[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)adalah layanan penandatanganan kode yang dikelola sepenuhnya yang memungkinkan Anda memvalidasi kode Anda terhadap tanda tangan digital untuk mengonfirmasi bahwa kode tidak berubah dan dari penerbit tepercaya. AWS Signer dapat digunakan bersama dengan AWS Lambda untuk memverifikasi bahwa fungsi dan lapisan tidak berubah sebelum penerapan ke lingkungan Anda. AWS Ini melindungi organisasi Anda dari pelaku jahat yang mungkin telah memperoleh kredensi untuk membuat fungsi baru atau memperbarui fungsi yang ada.
Untuk menyiapkan penandatanganan kode untuk fungsi Lambda Anda, mulailah dengan membuat bucket S3 dengan mengaktifkan versi. Setelah itu, buat profil penandatanganan dengan AWS Signer, tentukan Lambda sebagai platform dan kemudian tentukan periode hari di mana profil penandatanganan valid. Contoh:
```
Signer:
Type: AWS::Signer::SigningProfile
Properties:
PlatformId: AWSLambda-SHA384-ECDSA
SignatureValidityPeriod:
Type: DAYS
Value: !Ref pValidDays
```
Kemudian gunakan profil penandatanganan dan buat konfigurasi penandatanganan dengan Lambda. Anda harus menentukan apa yang harus dilakukan ketika konfigurasi penandatanganan melihat artefak yang tidak cocok dengan tanda tangan digital yang diharapkan: peringatkan (tetapi izinkan penerapan) atau terapkan (dan blokir penerapan). Contoh di bawah ini dikonfigurasi untuk menegakkan dan memblokir penerapan.
```
SigningConfig:
Type: AWS::Lambda::CodeSigningConfig
Properties:
AllowedPublishers:
SigningProfileVersionArns:
- !GetAtt Signer.ProfileVersionArn
CodeSigningPolicies:
UntrustedArtifactOnDeployment: Enforce
```
Anda sekarang telah AWS Signer mengonfigurasi dengan Lambda untuk memblokir penerapan yang tidak tepercaya. Mari kita asumsikan Anda telah selesai mengkodekan permintaan fitur dan sekarang siap untuk menerapkan fungsi. Langkah pertama adalah mem-zip kode dengan dependensi yang sesuai dan kemudian menandatangani artefak menggunakan profil penandatanganan yang Anda buat. Anda dapat melakukan ini dengan mengunggah artefak zip ke bucket S3 dan kemudian memulai pekerjaan penandatanganan.
```
aws signer start-signing-job \
--source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \
--destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \
--profile-name your-signer-id
```
Anda mendapatkan output sebagai berikut, di mana `jobId` adalah objek yang dibuat di bucket tujuan dan awalan dan `jobOwner` merupakan Akun AWS ID 12 digit tempat pekerjaan dijalankan.
```
{
"jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388",
"jobOwner": "111122223333"
}
```
Dan sekarang Anda dapat menerapkan fungsi Anda menggunakan objek S3 yang ditandatangani dan konfigurasi penandatanganan kode yang Anda buat.
```
Fn:
Type: AWS::Serverless::Function
Properties:
CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip
Handler: fn.handler
Role: !GetAtt FnRole.Arn
CodeSigningConfigArn: !Ref pSigningConfigArn
```
Sebagai alternatif, Anda dapat menguji penerapan fungsi dengan artefak zip sumber asli yang tidak ditandatangani. Penerapan akan gagal dengan pesan berikut:
```
Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned.
```
Jika Anda membangun dan menerapkan fungsi Anda menggunakan AWS Serverless Application Model (AWS SAM), perintah paket menangani pengunggahan artefak zip ke S3 dan juga memulai pekerjaan penandatanganan dan mendapatkan artefak yang ditandatangani. Anda dapat melakukan ini dengan perintah dan parameter berikut:
```
sam package -t your-template.yaml \
--output-template-file your-output.yaml \
--s3-bucket your-versioned-bucket \
--s3-prefix your-prefix \
--signing-profiles your-signer-id
```
AWS Signer membantu Anda memverifikasi bahwa artefak zip yang disebarkan ke akun Anda dipercaya untuk digunakan. Anda dapat menyertakan proses di atas dalam pipeline CI/CD Anda dan mengharuskan semua fungsi memiliki konfigurasi penandatanganan kode yang dilampirkan menggunakan teknik yang diuraikan dalam topik sebelumnya. Dengan menggunakan penandatanganan kode dengan penerapan fungsi Lambda, Anda mencegah pelaku jahat yang mungkin mendapatkan kredensi untuk membuat atau memperbarui fungsi agar tidak menyuntikkan kode berbahaya ke dalam fungsi Anda.
# Otomatiskan penilaian keamanan untuk Lambda dengan Amazon Inspector
[Amazon Inspector](https://aws.amazon.com/inspector/) adalah layanan manajemen kerentanan yang terus-menerus memindai beban kerja untuk kerentanan perangkat lunak yang diketahui dan paparan jaringan yang tidak diinginkan. Amazon Inspector membuat temuan yang menjelaskan kerentanan, mengidentifikasi sumber daya yang terpengaruh, menilai tingkat keparahan kerentanan, dan memberikan panduan remediasi.
Dukungan Amazon Inspector menyediakan penilaian kerentanan keamanan otomatis yang berkelanjutan untuk fungsi dan lapisan Lambda. Amazon Inspector menyediakan dua jenis pemindaian untuk Lambda:
+ **Pemindaian standar Lambda (default): Memindai** [dependensi aplikasi dalam fungsi Lambda dan lapisannya untuk kerentanan paket.](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package)
+ **Pemindaian kode Lambda: Memindai** [kode aplikasi khusus di fungsi dan lapisan Anda untuk mencari kerentanan kode.](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code) Anda dapat mengaktifkan pemindaian standar Lambda atau mengaktifkan pemindaian standar Lambda bersama dengan pemindaian kode Lambda.
****Untuk mengaktifkan Amazon Inspector, navigasikan ke konsol [Amazon Inspector](https://console.aws.amazon.com/inspector/), perluas bagian Pengaturan, dan pilih Manajemen Akun.**** Pada tab **Akun**, pilih **Aktifkan**, lalu pilih salah satu opsi pemindaian.
Anda dapat mengaktifkan Amazon Inspector untuk beberapa akun dan mendelegasikan izin untuk mengelola Amazon Inspector bagi organisasi ke akun tertentu saat menyiapkan Amazon Inspector. Saat mengaktifkan, Anda perlu memberikan izin Amazon Inspector dengan membuat peran:. `AWSServiceRoleForAmazonInspector2` Konsol Amazon Inspector memungkinkan Anda membuat peran ini menggunakan opsi sekali klik.
Untuk pemindaian standar Lambda, Amazon Inspector memulai pemindaian kerentanan fungsi Lambda dalam situasi berikut:
+ Segera setelah Amazon Inspector menemukan fungsi Lambda yang ada.
+ Saat Anda menerapkan fungsi Lambda baru.
+ Saat Anda menerapkan pembaruan ke kode aplikasi atau dependensi fungsi Lambda yang ada atau lapisannya.
+ Setiap kali Amazon Inspector menambahkan item common vulnerabilities and exposure (CVE) baru ke database-nya, dan CVE tersebut relevan dengan fungsi Anda.
Untuk pemindaian kode Lambda, Amazon Inspector mengevaluasi kode aplikasi fungsi Lambda Anda menggunakan penalaran otomatis dan pembelajaran mesin yang menganalisis kode aplikasi Anda untuk kepatuhan keamanan secara keseluruhan. **Jika Amazon Inspector mendeteksi kerentanan dalam kode aplikasi fungsi Lambda Anda, Amazon Inspector menghasilkan temuan Kerentanan Kode yang terperinci.** Untuk daftar kemungkinan deteksi, lihat [Perpustakaan CodeGuru Detektor Amazon](https://docs.aws.amazon.com/codeguru/detector-library/).
Untuk melihat temuannya, buka konsol [Amazon Inspector](https://console.aws.amazon.com/inspector/). Pada menu **Temuan**, pilih **Dengan fungsi Lambda** untuk menampilkan hasil pemindaian keamanan yang dilakukan pada fungsi Lambda.
Untuk mengecualikan fungsi Lambda dari pemindaian standar, beri tag fungsi dengan pasangan kunci-nilai berikut:
+ `Key:InspectorExclusion`
+ `Value:LambdaStandardScanning`
Untuk mengecualikan fungsi Lambda dari pemindaian kode, beri tag fungsi dengan pasangan kunci-nilai berikut:
+ `Key:InspectorCodeExclusion`
+ `Value:``LambdaCodeScanning`
Misalnya, seperti yang ditunjukkan pada gambar berikut, Amazon Inspector secara otomatis mendeteksi kerentanan dan mengkategorikan temuan tipe **Kerentanan Kode, yang menunjukkan bahwa kerentanan** ada dalam kode fungsi, dan bukan di salah satu pustaka yang bergantung pada kode. Anda dapat memeriksa detail ini untuk fungsi tertentu atau beberapa fungsi sekaligus.
![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-code-scanning-1.png)
Anda dapat menyelam lebih jauh ke dalam masing-masing temuan ini dan belajar bagaimana memperbaiki masalah tersebut.
![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-code-scanning-2.png)
Saat bekerja dengan fungsi Lambda Anda, pastikan Anda mematuhi konvensi penamaan untuk fungsi Lambda Anda. Untuk informasi selengkapnya, lihat [Bekerja dengan variabel lingkungan Lambda](configuration-envvars.md).
Anda bertanggung jawab atas saran remediasi yang Anda terima. Selalu tinjau saran remediasi sebelum menerimanya. Anda mungkin perlu mengedit saran remediasi untuk memastikan bahwa kode Anda melakukan apa yang Anda inginkan.
# Menerapkan observabilitas untuk keamanan dan kepatuhan Lambda
AWS Config adalah alat yang berguna untuk menemukan dan memperbaiki sumber daya Tanpa AWS Server yang tidak sesuai. Setiap perubahan yang Anda buat pada sumber daya tanpa server Anda dicatat. AWS Config Selain itu, AWS Config memungkinkan Anda untuk menyimpan data snapshot konfigurasi pada S3. Anda dapat menggunakan Amazon Athena dan Amazon Quick untuk membuat dasbor dan melihat data. AWS Config Pada tahun[Mendeteksi penerapan dan konfigurasi Lambda yang tidak sesuai dengan AWS Config](governance-config-detection.md), kita membahas bagaimana kita dapat memvisualisasikan konfigurasi tertentu seperti lapisan Lambda. Topik ini memperluas konsep-konsep ini.
## Visibilitas ke konfigurasi Lambda
Anda dapat menggunakan kueri untuk menarik konfigurasi penting seperti Akun AWS ID, Wilayah, konfigurasi AWS X-Ray penelusuran, konfigurasi VPC, ukuran memori, runtime, dan tag. Berikut adalah contoh kueri yang dapat Anda gunakan untuk menarik informasi ini dari Athena:
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
account_id,
tags,
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.runtime') AS version
json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig
json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig
FROM
unnested
```
Anda dapat menggunakan kueri untuk membangun dasbor Cepat dan memvisualisasikan data. Untuk menggabungkan data konfigurasi AWS sumber daya, membuat tabel di Athena, dan membuat dasbor Cepat pada data dari Athena, lihat [Memvisualisasikan data AWS Config menggunakan Athena dan Amazon Quick di blog Operasi dan Manajemen Cloud](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/). AWS Khususnya, kueri ini juga mengambil informasi tag untuk fungsi. Ini memungkinkan wawasan yang lebih dalam tentang beban kerja dan lingkungan Anda, terutama jika Anda menggunakan tag khusus.
![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-observability-1.png)
Untuk informasi selengkapnya tentang tindakan yang dapat Anda lakukan, lihat [Mengatasi temuan observabilitas](#governance-observability-addressing) bagian nanti dalam topik ini.
## Visibilitas ke kepatuhan Lambda
Dengan data yang dihasilkan AWS Config, Anda dapat membuat dasbor tingkat organisasi untuk memantau kepatuhan. Hal ini memungkinkan pelacakan dan pemantauan yang konsisten terhadap:
+ Paket kepatuhan berdasarkan skor kepatuhan
+ Aturan oleh sumber daya yang tidak sesuai
+ Status kepatuhan
![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-observability-2.png)
Periksa setiap aturan untuk mengidentifikasi sumber daya yang tidak sesuai untuk aturan itu. Misalnya, jika organisasi Anda mengamanatkan bahwa semua fungsi Lambda harus dikaitkan dengan VPC dan jika Anda telah menerapkan AWS Config aturan untuk mengidentifikasi kepatuhan, Anda dapat memilih aturan dalam daftar `lambda-inside-vpc` di atas.
![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-observability-3.png)
Untuk informasi lebih lanjut tentang tindakan yang dapat Anda lakukan, lihat [Mengatasi temuan observabilitas](#governance-observability-addressing) bagian di bawah ini.
## Visibilitas ke batas fungsi Lambda menggunakan Security Hub CSPM
![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-observability-4.png)
Untuk memastikan bahwa AWS layanan termasuk Lambda digunakan dengan aman, AWS memperkenalkan Praktik Terbaik Keamanan Dasar v1.0.0. Serangkaian praktik terbaik ini memberikan pedoman yang jelas untuk mengamankan sumber daya dan data di AWS lingkungan, menekankan pentingnya mempertahankan postur keamanan yang kuat. Ini AWS Security Hub CSPM melengkapi ini dengan menawarkan pusat keamanan dan kepatuhan terpadu. Ini mengumpulkan, mengatur, dan memprioritaskan temuan keamanan dari berbagai layanan seperti AWS Amazon Inspector,, dan Amazon. AWS Identity and Access Management Access Analyzer GuardDuty
Jika Anda memiliki Security Hub CSPM, Amazon Inspector, IAM Access Analyzer, GuardDuty dan diaktifkan dalam organisasi Anda AWS , Security Hub CSPM secara otomatis mengumpulkan temuan dari layanan ini. Misalnya, mari kita pertimbangkan Amazon Inspector. Menggunakan Security Hub CSPM, Anda dapat secara efisien mengidentifikasi kerentanan kode dan paket dalam fungsi Lambda. Di konsol CSPM Security Hub, navigasikan ke bagian bawah berlabel **Temuan terbaru dari integrasi**. AWS Di sini, Anda dapat melihat dan menganalisis temuan yang bersumber dari berbagai AWS layanan terintegrasi.
![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-observability-5.png)
Untuk melihat detailnya, pilih tautan **Lihat temuan** di kolom kedua. Ini menampilkan daftar temuan yang disaring berdasarkan produk, seperti Amazon Inspector. Untuk membatasi pencarian Anda ke fungsi Lambda, setel `ResourceType` ke. `AwsLambdaFunction` Ini menampilkan temuan dari Amazon Inspector terkait dengan fungsi Lambda.
![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/governance-observability-6.png)
Untuk GuardDuty, Anda dapat mengidentifikasi pola lalu lintas jaringan yang mencurigakan. Anomali semacam itu mungkin menunjukkan adanya kode yang berpotensi berbahaya dalam fungsi Lambda Anda.
Dengan IAM Access Analyzer, Anda dapat memeriksa kebijakan, terutama kebijakan dengan pernyataan kondisi yang memberikan akses fungsi ke entitas eksternal. Selain itu, IAM Access Analyzer mengevaluasi izin yang ditetapkan saat menggunakan operasi [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)di Lambda API bersama file. `EventSourceToken`
## Mengatasi temuan observabilitas
Mengingat konfigurasi luas yang mungkin untuk fungsi Lambda dan persyaratannya yang berbeda, solusi otomatisasi standar untuk remediasi mungkin tidak sesuai dengan setiap situasi. Selain itu, perubahan diterapkan secara berbeda di berbagai lingkungan. Jika Anda menemukan konfigurasi apa pun yang tampaknya tidak sesuai, pertimbangkan pedoman berikut:
1. **Strategi penandaan**
Kami merekomendasikan untuk menerapkan strategi penandaan yang komprehensif. Setiap fungsi Lambda harus ditandai dengan informasi kunci seperti:
+ **Pemilik:** Orang atau tim yang bertanggung jawab atas fungsi tersebut.
+ **Lingkungan:** Produksi, pementasan, pengembangan, atau kotak pasir.
+ **Aplikasi:** Konteks yang lebih luas di mana fungsi ini berada, jika berlaku.
1. **Penjangkauan pemilik**
Alih-alih mengotomatiskan perubahan yang melanggar (seperti penyesuaian konfigurasi VPC), secara proaktif hubungi pemilik fungsi yang tidak sesuai (diidentifikasi oleh tag pemilik) dengan memberi mereka waktu yang cukup untuk:
+ Sesuaikan konfigurasi yang tidak sesuai pada fungsi Lambda.
+ Memberikan penjelasan dan meminta pengecualian, atau menyempurnakan standar kepatuhan.
1. **Mempertahankan database manajemen konfigurasi (CMDB)**
Meskipun tag dapat memberikan konteks langsung, mempertahankan CMDB terpusat dapat memberikan wawasan yang lebih dalam. Ini dapat menyimpan informasi yang lebih terperinci tentang setiap fungsi Lambda, dependensinya, dan metadata penting lainnya. CMDB adalah sumber daya yang sangat berharga untuk audit, pemeriksaan kepatuhan, dan mengidentifikasi pemilik fungsi.
Karena lanskap infrastruktur tanpa server terus berkembang, penting untuk mengadopsi sikap proaktif terhadap pemantauan. Dengan alat seperti AWS Config, Security Hub CSPM, dan Amazon Inspector, kemungkinan anomali atau konfigurasi yang tidak sesuai dapat diidentifikasi dengan cepat. Namun, alat saja tidak dapat memastikan kepatuhan total atau konfigurasi optimal. Sangat penting untuk memasangkan alat-alat ini dengan proses dan praktik terbaik yang terdokumentasi dengan baik.
+ **Umpan balik loop:** Setelah langkah-langkah remediasi dilakukan, pastikan ada loop umpan balik. Ini berarti meninjau kembali sumber daya yang tidak sesuai secara berkala untuk mengonfirmasi apakah sumber daya tersebut telah diperbarui atau masih berjalan dengan masalah yang sama.
+ **Dokumentasi:** Selalu dokumentasikan pengamatan, tindakan yang diambil, dan pengecualian apa pun yang diberikan. Dokumentasi yang tepat tidak hanya membantu selama audit tetapi juga membantu dalam meningkatkan proses untuk kepatuhan dan keamanan yang lebih baik di masa depan.
+ **Pelatihan dan kesadaran:** Memastikan bahwa semua pemangku kepentingan, terutama pemilik fungsi Lambda, secara teratur dilatih dan disadarkan akan praktik terbaik, kebijakan organisasi, dan mandat kepatuhan. Lokakarya reguler, webinar, atau sesi pelatihan dapat sangat membantu dalam memastikan semua orang berada di halaman yang sama dalam hal keamanan dan kepatuhan.
Kesimpulannya, sementara alat dan teknologi memberikan kemampuan yang kuat untuk mendeteksi dan menandai masalah potensial, elemen manusia—pemahaman, komunikasi, pelatihan, dan dokumentasi—tetap penting. Bersama-sama, mereka membentuk kombinasi yang kuat untuk memastikan bahwa fungsi Lambda Anda dan infrastruktur yang lebih luas tetap sesuai, aman, dan dioptimalkan untuk kebutuhan bisnis Anda.
# Validasi kepatuhan untuk AWS Lambda
Auditor pihak ketiga menilai keamanan dan kepatuhan AWS Lambda sebagai bagian dari beberapa program AWS kepatuhan. Program ini mencakup SOC, PCI, FedRAMP, HIPAA, dan lainnya.
Untuk daftar AWS layanan dalam lingkup program kepatuhan tertentu, lihat [AWS layanan dalam lingkup oleh program kepatuhan](https://aws.amazon.com/compliance/services-in-scope/). Untuk informasi umum, lihat [Program kepatuhan AWS](https://aws.amazon.com/compliance/programs/).
Anda dapat mengunduh laporan audit pihak ketiga menggunakan AWS Artifact. Untuk informasi lebih lanjut, lihat [Mengunduh Laporan di AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Tanggung jawab kepatuhan Anda saat menggunakan Lambda ditentukan oleh sensitivitas data Anda, tujuan kepatuhan perusahaan Anda, serta undang-undang dan peraturan yang berlaku. Anda dapat menerapkan kontrol tata kelola untuk memastikan bahwa fungsi Lambda perusahaan Anda memenuhi persyaratan kepatuhan Anda. Untuk informasi selengkapnya, lihat [Buat strategi tata kelola untuk fungsi dan lapisan Lambda](governance-concepts.md).
# Ketahanan di AWS Lambda
Infrastruktur AWS global dibangun di sekitar AWS Wilayah dan Zona Ketersediaan. AWS Wilayah menyediakan beberapa Availability Zone yang terpisah secara fisik dan terisolasi, yang terhubung dengan latensi rendah, throughput tinggi, dan jaringan yang sangat redundan. Dengan Zona Ketersediaan, Anda dapat merancang dan mengoperasikan aplikasi dan basis data yang secara otomatis melakukan failover di antara Zona Ketersediaan tanpa gangguan. Zona Ketersediaan memiliki ketersediaan dan toleransi kesalahan yang lebih baik, dan dapat diskalakan dibandingkan infrastruktur biasa yang terdiri dari satu atau beberapa pusat data.
Untuk informasi selengkapnya tentang AWS Wilayah dan Availability Zone, lihat [infrastruktur AWS global](https://aws.amazon.com/about-aws/global-infrastructure/).
Selain infrastruktur AWS global, Lambda menawarkan beberapa fitur untuk membantu mendukung ketahanan data dan kebutuhan cadangan Anda.
+ **Versioning** – Anda dapat menggunakan versioning di Lambda untuk menyimpan kode dan konfigurasi fungsi saat Anda mengembangkannya. Bersama dengan alias, Anda dapat menggunakan versioning untuk melakukan deployment blue/green dan rolling. Untuk detailnya, lihat [Kelola versi fungsi Lambda](configuration-versions.md).
+ **Penskalaan** – Ketika fungsi Anda menerima permintaan saat sedang memproses permintaan sebelumnya, Lambda meluncurkan instans lain dari fungsi Anda untuk menangani peningkatan beban. Lambda secara otomatis menyesuaikan skala untuk menangani 1.000 eksekusi bersamaan per Wilayah, dan [kuota](gettingstarted-limits.md) ini dapat ditingkatkan jika diperlukan. Untuk detailnya, lihat [Memahami penskalaan fungsi Lambda](lambda-concurrency.md).
+ **Ketersediaan tinggi** – Lambda menjalankan fungsi Anda di beberapa Availability Zone guna memastikannya tersedia untuk memproses kejadian jika terjadi gangguan layanan dalam satu zona. Jika Anda mengonfigurasikan fungsi Anda agar terhubung ke virtual private cloud (VPC) di akun Anda, tentukan subnet di beberapa Availability Zone untuk memastikan ketersediaan yang tinggi. Untuk detailnya, lihat [Memberikan fungsi Lambda akses ke sumber daya di VPC Amazon](configuration-vpc.md).
+ **Konkurensi cadangan** – Untuk memastikan bahwa fungsi Anda dapat selalu menskalakan untuk menangani permintaan tambahan, Anda dapat mencadangkan konkurensi untuk hal itu. Menetapkan konkurensi cadangan untuk suatu fungsi memastikan bahwa fungsi dapat menskalakan ke, tetapi tidak melebihi, jumlah invokasi bersamaan yang ditentukan. Hal ini memastikan bahwa Anda tidak kehilangan permintaan karena fungsi lain menggunakan semua konkurensi yang tersedia. Untuk detailnya, lihat [Mengkonfigurasi konkurensi cadangan untuk suatu fungsi](configuration-concurrency.md).
+ **Percobaan ulang** – Untuk invokasi asinkron dan subset invokasi yang dipicu oleh layanan lain, Lambda secara otomatis melakukan percobaan ulang terkait kesalahan dengan penundaan di antara percobaan. Klien lain dan Layanan AWS yang memanggil fungsi secara sinkron bertanggung jawab untuk melakukan percobaan ulang. Untuk detailnya, lihat [Memahami perilaku coba lagi di Lambda](invocation-retries.md).
+ **Antrean surat mati** – Untuk invokasi asinkron, Anda dapat mengonfigurasi Lambda agar mengirim permintaan ke antrean surat gagal jika semua percobaan ulang gagal. Antrean surat mati adalah topik Amazon SNS atau antrean Amazon SQS yang menerima kejadian untuk pemecahan masalah atau pemrosesan ulang. Untuk detailnya, lihat [Menambahkan antrian huruf mati](invocation-async-retain-records.md#invocation-dlq).
# Keamanan infrastruktur di AWS Lambda
Sebagai layanan terkelola, AWS Lambda dilindungi oleh keamanan jaringan AWS global. Untuk informasi tentang layanan AWS keamanan dan cara AWS melindungi infrastruktur, lihat [Keamanan AWS Cloud](https://aws.amazon.com/security/). Untuk mendesain AWS lingkungan Anda menggunakan praktik terbaik untuk keamanan infrastruktur, lihat [Perlindungan Infrastruktur dalam Kerangka Kerja](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) yang * AWS Diarsiteksikan dengan Baik Pilar Keamanan*.
Anda menggunakan panggilan API yang AWS dipublikasikan untuk mengakses Lambda melalui jaringan. Klien harus mendukung hal-hal berikut:
+ Keamanan Lapisan Pengangkutan (TLS). Kami mensyaratkan TLS 1.2 dan menganjurkan TLS 1.3.
+ Sandi cocok dengan sistem kerahasiaan maju sempurna (perfect forward secrecy, PFS) seperti DHE (Ephemeral Diffie-Hellman) atau ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Sebagian besar sistem modern seperti Java 7 dan versi lebih baru mendukung mode-mode ini.
# Mengamankan beban kerja dengan titik akhir publik
Untuk beban kerja yang dapat diakses publik, AWS menyediakan sejumlah fitur dan layanan yang dapat membantu mengurangi risiko tertentu. Bagian ini mencakup otentikasi dan otorisasi pengguna aplikasi dan melindungi titik akhir API.
## Autentikasi dan otorisasi
Otentikasi berkaitan dengan identitas dan otorisasi mengacu pada tindakan. Gunakan otentikasi untuk mengontrol siapa yang dapat menjalankan fungsi Lambda, dan kemudian gunakan otorisasi untuk mengontrol apa yang dapat mereka lakukan. Untuk banyak aplikasi, IAM cukup untuk mengelola kedua mekanisme kontrol.
Untuk aplikasi dengan pengguna eksternal, seperti aplikasi web atau seluler, biasanya menggunakan [JSON Web Tokens](https://jwt.io/introduction/) (JWTs) untuk mengelola otentikasi dan otorisasi. Tidak seperti manajemen kata sandi berbasis server tradisional, JWTs diteruskan dari klien pada setiap permintaan. Mereka adalah cara yang aman secara kriptografis untuk memverifikasi identitas dan klaim menggunakan data yang diteruskan dari klien. Untuk aplikasi berbasis Lambda, ini memungkinkan Anda mengamankan setiap panggilan ke setiap titik akhir API tanpa bergantung pada server pusat untuk otentikasi.
Anda dapat [menerapkan JWTs dengan Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html), layanan direktori pengguna yang dapat menangani pendaftaran, otentikasi, pemulihan akun, dan operasi manajemen akun umum lainnya. [Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) menyediakan library untuk menyederhanakan integrasi layanan ini ke dalam aplikasi frontend Anda. Anda juga dapat mempertimbangkan layanan mitra pihak ketiga seperti [Auth0](https://auth0.com/).
Mengingat peran keamanan penting dari layanan penyedia identitas, penting untuk menggunakan perkakas profesional untuk melindungi aplikasi Anda. Anda tidak disarankan untuk menulis layanan Anda sendiri untuk menangani otentikasi atau otorisasi. Kerentanan apa pun di pustaka khusus mungkin memiliki implikasi signifikan terhadap keamanan beban kerja Anda dan datanya.
## Melindungi titik akhir API
Untuk aplikasi tanpa server, cara yang lebih disukai untuk melayani aplikasi backend secara publik adalah dengan menggunakan Amazon API Gateway. Ini dapat membantu Anda melindungi API dari pengguna jahat atau lonjakan lalu lintas.
[API Gateway menawarkan dua tipe endpoint untuk pengembang tanpa server: [REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) dan HTTP. APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html) Keduanya mendukung [otorisasi menggunakan AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html), IAM, atau Amazon Cognito. Saat menggunakan IAM atau Amazon Cognito, permintaan masuk dievaluasi dan jika tidak ada token yang diperlukan atau berisi otentikasi yang tidak valid, permintaan tersebut ditolak. Anda tidak dikenakan biaya untuk permintaan ini dan mereka tidak dihitung terhadap kuota pembatasan apa pun.
Rute API yang tidak diautentikasi dapat diakses oleh siapa saja di internet publik sehingga Anda disarankan untuk membatasi penggunaan yang tidak diautentikasi. APIs Jika Anda harus menggunakan yang tidak diautentikasi APIs, penting untuk melindungi ini dari risiko umum, seperti [ denial-of-service](https://en.wikipedia.org/wiki/Denial-of-service_attack)serangan (DoS). [AWS WAF Menerapkan](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) ini APIs dapat membantu melindungi aplikasi Anda dari injeksi SQL dan serangan cross-site scripting (XSS). API Gateway juga mengimplementasikan [pembatasan](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) pada tingkat AWS akun dan tingkat per klien saat kunci API digunakan.
Dalam banyak kasus, fungsionalitas yang disediakan oleh API yang tidak diautentikasi dapat dicapai dengan pendekatan alternatif. Misalnya, aplikasi web dapat menyediakan daftar toko ritel pelanggan dari tabel DynamoDB kepada pengguna yang tidak masuk. Permintaan ini mungkin berasal dari aplikasi web frontend atau dari sumber lain yang memanggil titik akhir URL. Diagram ini membandingkan tiga solusi:
![\[operasi keamanan angka 5\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/security-ops-figure-5.png)
1. API yang tidak diautentikasi ini dapat dipanggil oleh siapa saja di internet. Dalam serangan denial of service, dimungkinkan untuk menghabiskan batas pelambatan API, konkurensi Lambda, atau kapasitas baca yang disediakan DynamoDB pada tabel yang mendasarinya.
1. CloudFront Distribusi di depan titik akhir API dengan konfigurasi [ time-to-live](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html)(TTL) yang sesuai akan menyerap sebagian besar lalu lintas dalam serangan DoS, tanpa mengubah solusi mendasar untuk mengambil data.
1. Atau, untuk data statis yang jarang berubah, CloudFront distribusi dapat menyajikan data' dari bucket Amazon S3.
# Menggunakan penandatanganan kode untuk memverifikasi integritas kode dengan Lambda
Penandatanganan kode membantu memastikan bahwa hanya kode tepercaya yang diterapkan ke fungsi Lambda Anda. Dengan menggunakan AWS Signer, Anda dapat membuat paket kode yang ditandatangani secara digital untuk fungsi Anda. Saat Anda [menambahkan konfigurasi penandatanganan kode ke fungsi](configuration-codesigning-create.md), Lambda memverifikasi bahwa semua penerapan kode baru ditandatangani oleh sumber tepercaya. Karena pemeriksaan validasi penandatanganan kode berjalan pada waktu penerapan, tidak ada dampak pada eksekusi fungsi.
**penting**
Konfigurasi penandatanganan kode hanya mencegah penerapan baru kode yang tidak ditandatangani. Jika Anda menambahkan konfigurasi penandatanganan kode ke fungsi yang sudah ada yang memiliki kode yang tidak ditandatangani, kode tersebut akan terus berjalan hingga Anda menerapkan paket kode baru.
Saat Anda mengaktifkan penandatanganan kode untuk suatu fungsi, [lapisan](chapter-layers.md) apa pun yang Anda tambahkan ke fungsi juga harus ditandatangani oleh profil penandatanganan yang diizinkan.
Tidak ada biaya tambahan untuk penggunaan AWS Signer atau penandatanganan kode untuk AWS Lambda.
## Validasi tanda tangan
Lambda melakukan pemeriksaan validasi berikut saat Anda men-deploy paket kode yang ditandatangani ke fungsi Anda:
1. **Integritas**: Memvalidasi bahwa paket kode belum dimodifikasi sejak ditandatangani. Lambda membandingkan hash paket dengan hash dari tanda tangan.
1. **Kedaluwarsa**: Memvalidasi bahwa tanda tangan paket kode belum kedaluwarsa.
1. **Ketidakcocokan**: Memvalidasi bahwa paket kode ditandatangani dengan profil penandatanganan yang diizinkan
1. **Pencabutan**: Memvalidasi bahwa tanda tangan paket kode belum dicabut.
Saat membuat konfigurasi penandatanganan kode, Anda dapat menggunakan [UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment)parameter untuk menentukan respons Lambda jika pemeriksaan kedaluwarsa, ketidakcocokan, atau pencabutan gagal. Anda dapat memilih salah satu dari tindakan ini:
+ `Warn`: Ini adalah pengaturan default. Lambda memungkinkan penyebaran paket kode, tetapi mengeluarkan peringatan. Lambda mengeluarkan CloudWatch metrik Amazon baru (`SignatureValidationErrors`) dan juga menyimpan peringatan di log. CloudTrail
+ `Enforce`Lambda mengeluarkan peringatan (sama seperti untuk `Warn` tindakan) dan memblokir penerapan paket kode.
**Topics**
+ [Validasi tanda tangan](#config-codesigning-valid)
+ [Membuat konfigurasi penandatanganan kode untuk Lambda](configuration-codesigning-create.md)
+ [Mengonfigurasi kebijakan IAM untuk konfigurasi penandatanganan kode Lambda](config-codesigning-policies.md)
+ [Menggunakan tag pada konfigurasi penandatanganan kode](tags-csc.md)
# Membuat konfigurasi penandatanganan kode untuk Lambda
Untuk mengaktifkan penandatanganan kode untuk fungsi, Anda membuat *konfigurasi penandatanganan kode* dan melampirkannya ke fungsi. Konfigurasi penandatanganan kode menetapkan daftar profil penandatanganan yang diizinkan dan tindakan kebijakan yang harus diambil jika pemeriksaan validasi gagal.
**catatan**
Fungsi yang ditentukan sebagai gambar kontainer tidak mendukung penandatanganan kode.
**Topics**
+ [Prasyarat konfigurasi](#config-codesigning-prereqs)
+ [Membuat konfigurasi penandatanganan kode](#config-codesigning-config-console)
+ [Mengaktifkan penandatanganan kode untuk fungsi](#config-codesigning-function-console)
## Prasyarat konfigurasi
Sebelum Anda dapat mengonfigurasi penandatanganan kode untuk fungsi Lambda, gunakan AWS Penandatangan untuk melakukan hal berikut:
+ Buat satu atau lebih [profil penandatanganan](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html).
+ Gunakan profil penandatanganan untuk [membuat paket kode yang ditandatangani untuk fungsi Anda](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html).
## Membuat konfigurasi penandatanganan kode
Konfigurasi penandatanganan kode menetapkan daftar profil penandatanganan yang diizinkan dan kebijakan validasi tanda tangan.
**Untuk membuat konfigurasi penandatanganan kode (konsol)**
1. Buka [Halaman konfigurasi penandatanganan kode](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) di konsol Lambda.
1. Pilih **Buat konfigurasi**.
1. Untuk **Deskripsi**, masukkan nama deskriptif untuk konfigurasi.
1. Di bawah **Profil penandatanganan**, tambahkan hingga 20 profil penandatanganan ke konfigurasi.
1. Untuk **ARN versi profil penandatanganan**, pilih Amazon Resource Name (ARN) dari versi profil, atau masukkan ARN.
1. Untuk menambahkan profil penandatanganan tambahan, pilih **Tambahkan profil penandatanganan**.
1. Di bawah **Kebijakan validasi tanda tangan**, pilih **Warn** atau **Enforce**.
1. Pilih **Buat konfigurasi**.
## Mengaktifkan penandatanganan kode untuk fungsi
Untuk mengaktifkan penandatanganan kode untuk suatu fungsi, tambahkan konfigurasi penandatanganan kode ke fungsi.
**penting**
Konfigurasi penandatanganan kode hanya mencegah penerapan baru kode yang tidak ditandatangani. Jika Anda menambahkan konfigurasi penandatanganan kode ke fungsi yang sudah ada yang memiliki kode yang tidak ditandatangani, kode tersebut akan terus berjalan hingga Anda menerapkan paket kode baru.
**Untuk mengaitkan konfigurasi penandatanganan kode dengan fungsi (konsol)**
1. Buka [Halaman fungsi](https://console.aws.amazon.com/lambda/home#/functions) di konsol Lambda.
1. Pilih fungsi yang ingin Anda aktifkan penandatanganan kodenya.
1. Buka tab **Konfigurasi**.
1. Gulir ke bawah dan pilih **Penandatanganan kode**.
1. Pilih **Edit**.
1. Di **Edit penandatanganan kode**, pilih konfigurasi penandatanganan kode untuk fungsi ini.
1. Pilih **Simpan**.
# Mengonfigurasi kebijakan IAM untuk konfigurasi penandatanganan kode Lambda
Untuk memberikan izin bagi pengguna untuk mengakses operasi API penandatanganan kode Lambda, lampirkan satu atau beberapa pernyataan kebijakan ke kebijakan pengguna. Untuk informasi selengkapnya tentang kebijakan pengguna, lihat [Kebijakan IAM berbasis identitas untuk Lambda](access-control-identity-based.md).
Contoh pernyataan kebijakan berikut memberikan izin untuk membuat, memperbarui, dan mengambil konfigurasi penandatanganan kode.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:CreateCodeSigningConfig",
"lambda:UpdateCodeSigningConfig",
"lambda:GetCodeSigningConfig"
],
"Resource": "*"
}
]
}
```
------
Administrator dapat menggunakan kunci syarat `CodeSigningConfigArn` untuk menentukan konfigurasi penandatanganan kode yang harus digunakan developer untuk membuat atau memperbarui fungsi Anda.
Contoh pernyataan kebijakan berikut memberikan izin untuk membuat fungsi. Pernyataan kebijakan mencakup syarat `lambda:CodeSigningConfigArn` untuk menentukan konfigurasi penandatanganan kode yang diizinkan. Lambda memblokir permintaan `CreateFunction` API jika [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn)parameter hilang atau tidak cocok dengan nilai dalam kondisi.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowReferencingCodeSigningConfig",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6"
}
}
}
]
}
```
------
# Menggunakan tag pada konfigurasi penandatanganan kode
Anda dapat menandai konfigurasi penandatanganan kode untuk mengatur dan mengelola sumber daya Anda. Tag adalah pasangan nilai kunci bentuk bebas yang terkait dengan sumber daya Anda yang didukung secara keseluruhan. Layanan AWS Untuk informasi selengkapnya tentang kasus penggunaan tag, lihat [Strategi penandaan umum](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) di * AWS Sumber Daya Penandaan dan Panduan Editor Tag*.
Anda dapat menggunakan AWS Lambda API untuk melihat dan memperbarui tag. Anda juga dapat melihat dan memperbarui tag sambil mengelola konfigurasi penandatanganan kode tertentu di konsol Lambda.
**Topics**
+ [Izin diperlukan untuk bekerja dengan tag](#csc-tags-required-permissions)
+ [Menggunakan tag dengan konsol Lambda](#tags-csc-console)
+ [Menggunakan tag dengan AWS CLI](#tags-csc-cli)
## Izin diperlukan untuk bekerja dengan tag
Untuk mengizinkan identitas AWS Identity and Access Management (IAM) (pengguna, grup, atau peran) membaca atau menyetel tag pada sumber daya, berikan izin yang sesuai:
+ **lambda: ListTags** —Ketika sumber daya memiliki tag, berikan izin ini kepada siapa saja yang perlu memanggilnya`ListTags`. Untuk fungsi yang ditandai, izin ini juga diperlukan untuk`GetFunction`.
+ **lambda: TagResource** —Berikan izin ini kepada siapa saja yang perlu memanggil `TagResource` atau melakukan tag saat membuat.
Secara opsional, pertimbangkan untuk memberikan UntagResource izin **lambda:** juga untuk mengizinkan `UntagResource` panggilan ke sumber daya.
Untuk informasi selengkapnya, lihat [Kebijakan IAM berbasis identitas untuk Lambda](access-control-identity-based.md).
## Menggunakan tag dengan konsol Lambda
Anda dapat menggunakan konsol Lambda untuk membuat konfigurasi penandatanganan kode yang memiliki tag, menambahkan tag ke konfigurasi penandatanganan kode yang ada, dan memfilter konfigurasi penandatanganan kode berdasarkan tag.
**Untuk menambahkan tag saat Anda membuat konfigurasi penandatanganan kode**
1. Buka [konfigurasi penandatanganan Kode](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) di konsol Lambda.
1. Dari header panel konten, Pilih **Buat konfigurasi**.
1. Di bagian di bagian atas panel konten, atur konfigurasi penandatanganan kode Anda. Untuk informasi selengkapnya tentang mengonfigurasi konfigurasi penandatanganan kode, lihat. [Menggunakan penandatanganan kode untuk memverifikasi integritas kode dengan Lambda](configuration-codesigning.md)
1. Di bagian **Tag**, pilih **Tambahkan tag baru**.
1. Di bidang **Key**, masukkan kunci tag Anda. Untuk informasi tentang pembatasan penandaan, lihat [Batas dan persyaratan penamaan tag](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) di Panduan * AWS Sumber Daya Penandaan dan Editor Tag*.
1. Pilih **Buat konfigurasi**.
**Untuk menambahkan tag ke konfigurasi penandatanganan kode yang ada**
1. Buka [konfigurasi penandatanganan Kode](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) di konsol Lambda.
1. Pilih nama konfigurasi penandatanganan kode Anda.
1. **Pada tab di bawah panel **Detail**, pilih Tag.**
1. Pilih **Kelola tanda**.
1. Pilih **Tambahkan tag baru**.
1. Di bidang **Key**, masukkan kunci tag Anda. Untuk informasi tentang pembatasan penandaan, lihat [Batas dan persyaratan penamaan tag](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) di Panduan * AWS Sumber Daya Penandaan dan Editor Tag*.
1. Pilih **Simpan**.
**Untuk memfilter konfigurasi penandatanganan kode berdasarkan tag**
1. Buka [konfigurasi penandatanganan Kode](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) di konsol Lambda.
1. Pilih kotak pencarian.
1. Dari daftar dropdown, pilih tag Anda dari bawah subjudul **Tag**.
1. Pilih **Gunakan: “tag-name”** untuk melihat semua konfigurasi penandatanganan kode yang ditandai dengan kunci ini, atau pilih **Operator** untuk memfilter lebih lanjut berdasarkan nilai.
1. Pilih nilai tag Anda untuk difilter dengan kombinasi kunci tag dan nilai.
Kotak pencarian juga mendukung pencarian kunci tag. Masukkan nama kunci untuk menemukannya dalam daftar.
## Menggunakan tag dengan AWS CLI
Anda dapat menambahkan dan menghapus tag pada resource Lambda yang ada, termasuk konfigurasi penandatanganan kode, dengan API Lambda. Anda juga dapat menambahkan tag saat membuat konfigurasi penandatanganan kode, yang memungkinkan Anda menyimpan sumber daya yang ditandai melalui seluruh siklus hidupnya.
### Memperbarui tag dengan tag Lambda APIs
Anda dapat menambahkan dan menghapus tag untuk sumber daya Lambda yang didukung melalui operasi [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)dan [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)API.
Anda dapat memanggil operasi ini menggunakan AWS CLI. Untuk menambahkan tag ke sumber daya yang ada, gunakan `tag-resource` perintah. Contoh ini menambahkan dua tag, satu dengan kunci *Department* dan satu dengan kunci*CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Untuk menghapus tanda, gunakan perintah `untag-resource`. Contoh ini menghapus tag dengan kunci*Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Menambahkan tag saat membuat konfigurasi penandatanganan kode
Untuk membuat konfigurasi penandatanganan kode Lambda baru dengan tag, gunakan operasi [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html)API. Tentukan parameter `Tags`. Anda dapat memanggil operasi ini dengan `create-code-signing-config` AWS CLI perintah dan `--tags` opsi. *Untuk informasi selengkapnya tentang perintah CLI, lihat [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html)di Command Reference AWS CLI .*
Sebelum menggunakan `Tags` parameter dengan`CreateCodeSigningConfig`, pastikan bahwa peran Anda memiliki izin untuk menandai sumber daya bersama izin yang biasa diperlukan untuk operasi ini. Untuk informasi selengkapnya tentang izin untuk menandai, lihat. [Izin diperlukan untuk bekerja dengan tag](#csc-tags-required-permissions)
### Melihat tag dengan tag Lambda APIs
Untuk melihat tag yang diterapkan ke sumber daya Lambda tertentu, gunakan operasi `ListTags` API. Untuk informasi selengkapnya, lihat [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
Anda dapat memanggil operasi ini dengan `list-tags` AWS CLI perintah dengan memberikan ARN (Nama Sumber Daya Amazon).
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### Memfilter sumber daya berdasarkan tag
Anda dapat menggunakan operasi AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html)API untuk memfilter sumber daya berdasarkan tag. `GetResources`Operasi menerima hingga 10 filter, dengan setiap filter berisi kunci tag dan hingga 10 nilai tag. Anda `GetResources` menyediakan `ResourceType` untuk memfilter berdasarkan jenis sumber daya tertentu.
Anda dapat memanggil operasi ini menggunakan `get-resources` AWS CLI perintah. Untuk contoh penggunaan`get-resources`, lihat [mendapatkan sumber daya di Referensi](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) Perintah *AWS CLI*.