Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # 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.