Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

src/pentesting-ci-cd/serverless.com-security.md

@@ -14,7 +14,7 @@
 
 ### 애플리케이션
 
-**앱**은 조직 내 관련 서비스의 논리적 그룹화입니다. 이는 여러 서버리스 서비스로 구성된 완전한 애플리케이션을 나타내며, 이 서비스들은 함께 작동하여 일관된 기능을 제공합니다.
+**앱**은 조직 내에서 관련 서비스의 논리적 그룹화입니다. 이는 여러 서버리스 서비스로 구성된 완전한 애플리케이션을 나타내며, 이 서비스들은 함께 작동하여 일관된 기능을 제공합니다.
 
 ### **서비스**
 
@@ -98,7 +98,7 @@ WriteCapacityUnits: 1
 
 **Provider** 객체는 클라우드 서비스 제공업체(예: AWS, Azure, Google Cloud)를 지정하고 해당 제공업체와 관련된 구성 설정을 포함합니다.
 
-여기에는 런타임, 지역, 단계 및 자격 증명과 같은 세부 정보가 포함됩니다.
+런타임, 지역, 단계 및 자격 증명과 같은 세부정보를 포함합니다.
 ```yaml
 yamlCopy codeprovider:
 name: aws
@@ -128,7 +128,7 @@ region: us-west-2
 
 <summary>플러그인</summary>
 
-**플러그인**은 새로운 기능을 추가하거나 다른 도구 및 서비스와 통합하여 Serverless Framework의 기능을 확장합니다. 이들은 `plugins` 섹션 아래에 정의되며 npm을 통해 설치됩니다.
+**플러그인**은 새로운 기능을 추가하거나 다른 도구 및 서비스와 통합하여 Serverless Framework의 기능을 확장합니다. 이들은 `plugins` 섹션에 정의되며 npm을 통해 설치됩니다.
 ```yaml
 plugins:
 - serverless-offline
@@ -138,9 +138,9 @@ plugins:
 
 <details>
 
-<summary>Layers</summary>
+<summary>레이어</summary>
 
-**Layers**는 공유 코드나 종속성을 함수와 별도로 패키징하고 관리할 수 있게 해줍니다. 이는 재사용성을 촉진하고 배포 패키지 크기를 줄입니다. 이들은 `layers` 섹션 아래에 정의되며 함수에서 참조됩니다.
+**레이어**는 공유 코드 또는 종속성을 함수와 별도로 패키징하고 관리할 수 있게 해줍니다. 이는 재사용성을 촉진하고 배포 패키지 크기를 줄입니다. 레이어는 `layers` 섹션 아래에 정의되며 함수에서 참조됩니다.
 ```yaml
 layers:
 commonLibs:
@@ -157,7 +157,7 @@ layers:
 
 <summary>변수 및 사용자 정의 변수</summary>
 
-**변수**는 배포 시점에 해결되는 플레이스홀더를 사용하여 동적 구성을 가능하게 합니다.
+**변수**는 배포 시 해결되는 자리 표시자를 사용하여 동적 구성을 가능하게 합니다.
 
 - **구문:** `${variable}` 구문은 환경 변수, 파일 내용 또는 기타 구성 매개변수를 참조할 수 있습니다.
 
@@ -169,7 +169,7 @@ environment:
 TABLE_NAME: ${self:custom.tableName}
 ```
 
-* **사용자 정의 변수:** `custom` 섹션은 `serverless.yml` 전반에 걸쳐 재사용할 수 있는 사용자 지정 변수 및 구성을 정의하는 데 사용됩니다.
+* **사용자 정의 변수:** `custom` 섹션은 `serverless.yml` 전반에 걸쳐 재사용할 수 있는 사용자 특정 변수 및 구성을 정의하는 데 사용됩니다.
 
 ```yaml
 custom:
@@ -183,7 +183,7 @@ stage: ${opt:stage, 'dev'}
 
 <summary>출력</summary>
 
-**출력**은 서비스가 배포된 후 반환되는 값들을 정의하며, 리소스 ARN, 엔드포인트 또는 기타 유용한 정보가 포함됩니다. 이들은 `outputs` 섹션 아래에 지정되며, 다른 서비스에 정보를 노출하거나 배포 후 쉽게 접근할 수 있도록 자주 사용됩니다.
+**출력**은 서비스가 배포된 후 반환되는 값들을 정의하며, 리소스 ARN, 엔드포인트 또는 기타 유용한 정보가 포함됩니다. 이들은 `outputs` 섹션 아래에 지정되며, 종종 다른 서비스에 정보를 노출하거나 배포 후 쉽게 접근할 수 있도록 사용됩니다.
 ```yaml
 ¡outputs:
 ApiEndpoint:
@@ -226,7 +226,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
 
 <summary>환경 변수</summary>
 
-**변수**는 하드코딩하지 않고 구성 설정 및 비밀을 함수에 전달할 수 있게 해줍니다. 이들은 제공자 또는 개별 함수의 `environment` 섹션 아래에 정의됩니다.
+**변수**는 하드코딩하지 않고도 구성 설정 및 비밀을 함수에 전달할 수 있게 해줍니다. 이들은 제공자 또는 개별 함수의 `environment` 섹션 아래에 정의됩니다.
 ```yaml
 provider:
 environment:
@@ -243,7 +243,7 @@ TABLE_NAME: ${self:custom.tableName}
 
 <summary>종속성</summary>
 
-**종속성**은 함수가 필요로 하는 외부 라이브러리와 모듈을 관리합니다. 일반적으로 npm이나 pip와 같은 패키지 관리자를 통해 처리되며, `serverless-webpack`과 같은 도구나 플러그인을 사용하여 배포 패키지와 함께 번들됩니다.
+**종속성**은 함수에 필요한 외부 라이브러리와 모듈을 관리합니다. 일반적으로 npm 또는 pip와 같은 패키지 관리자를 통해 처리되며, `serverless-webpack`과 같은 도구나 플러그인을 사용하여 배포 패키지와 함께 번들됩니다.
 ```yaml
 plugins:
 - serverless-webpack
@@ -252,9 +252,9 @@ plugins:
 
 <details>
 
-<summary>Hooks</summary>
+<summary>후크</summary>
 
-**Hooks**는 배포 생애 주기의 특정 지점에서 사용자 정의 스크립트나 명령을 실행할 수 있게 해줍니다. 이들은 플러그인을 사용하거나 `serverless.yml` 내에서 정의되어 배포 전후에 작업을 수행합니다.
+**후크**는 배포 생애 주기의 특정 지점에서 사용자 정의 스크립트나 명령을 실행할 수 있게 해줍니다. 이들은 플러그인을 사용하거나 `serverless.yml` 내에서 정의되어 배포 전후에 작업을 수행합니다.
 ```yaml
 custom:
 hooks:
@@ -262,13 +262,13 @@ before:deploy:deploy: echo "Starting deployment..."
 ```
 </details>
 
-### Tutorial
+### 튜토리얼
 
-이것은 공식 튜토리얼 [**문서에서**](https://www.serverless.com/framework/docs/tutorial)의 요약입니다:
+이것은 공식 튜토리얼의 요약입니다 [**문서에서**](https://www.serverless.com/framework/docs/tutorial):
 
-1. AWS 계정을 생성합니다 (Serverless.com은 AWS 인프라에서 시작합니다)
-2. serverless.com에 계정을 생성합니다
-3. 앱을 생성합니다:
+1. AWS 계정 생성 (Serverless.com은 AWS 인프라에서 시작)
+2. serverless.com에 계정 생성
+3. 앱 생성:
 ```bash
 # Create temp folder for the tutorial
 mkdir /tmp/serverless-tutorial
@@ -284,7 +284,7 @@ serverless #Choose first one (AWS / Node.js / HTTP API)
 ## Create A New App
 ## Indicate a name like "tutorialapp)
 ```
-이것은 **app** `tutorialapp`을 생성했어야 하며, [serverless.com](serverless.com-security.md)에서 확인할 수 있고, `helloworld` 코드가 포함된 JS 코드가 있는 **`handler.js`** 파일과 해당 함수를 선언하는 **`serverless.yml`** 파일이 있는 `Tutorial`이라는 폴더를 생성했어야 합니다:
+이것은 **app**인 `tutorialapp`을 생성했어야 하며, [serverless.com](serverless.com-security.md)에서 확인할 수 있고, `helloworld` 코드가 포함된 JS 코드가 있는 **`handler.js`** 파일과 해당 함수를 선언하는 **`serverless.yml`** 파일이 있는 `Tutorial`이라는 폴더를 생성했어야 합니다:
 
 {{#tabs }}
 {{#tab name="handler.js" }}
@@ -323,9 +323,9 @@ method: get
 {{#endtab }}
 {{#endtabs }}
 
-4. AWS 공급자를 생성하려면 `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`의 **대시보드**로 이동합니다.
-1. `serverless.com`에 AWS 접근 권한을 부여하기 위해 이 구성 파일을 사용하여 클라우드포메이션 스택을 실행하라는 요청이 있습니다(이 글을 작성할 당시): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
-2. 이 템플릿은 **`SFRole-<ID>`**라는 역할을 생성하며, **`arn:aws:iam::aws:policy/AdministratorAccess`**를 통해 `Serverless.com` AWS 계정이 역할에 접근할 수 있도록 허용하는 신뢰 ID를 가진 계정에 대해 설정됩니다.
+4. **대시보드**에서 AWS 공급자를 생성합니다: `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
+1. `serverless.com`에 AWS 접근 권한을 부여하기 위해, 이 구성 파일을 사용하여 클라우드포메이션 스택을 실행하라는 요청이 있습니다 (이 글을 작성할 당시): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
+2. 이 템플릿은 **`SFRole-<ID>`**라는 역할을 생성하며, **`arn:aws:iam::aws:policy/AdministratorAccess`**를 통해 `Serverless.com` AWS 계정이 역할에 접근할 수 있도록 허용하는 신뢰 ID를 갖습니다.
 
 <details>
 
@@ -481,11 +481,11 @@ TableName: ${self:service}-customerTable-${sls:stage}
 {{#endtab }}
 {{#endtabs }}
 
-6. **`serverless deploy`**를 실행하여 배포합니다.
+6. **`serverless deploy`** 명령어로 배포합니다.
 1. 배포는 CloudFormation Stack을 통해 수행됩니다.
 2. **람다 함수는 직접 URL이 아닌 API 게이트웨이를 통해 노출됩니다.**
 7. **테스트합니다.**
-1. 이전 단계에서는 API 엔드포인트 람다 함수가 배포된 **URL**이 출력됩니다.
+1. 이전 단계에서는 API 엔드포인트 람다 함수가 배포된 **URL**을 출력합니다.
 
 ## Serverless.com의 보안 검토
 
@@ -545,14 +545,14 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
 
 ---
 
-### **불안전한 비밀 및 구성 관리**
+### **안전하지 않은 비밀 및 구성 관리**
 
 민감한 정보(예: API 키, 데이터베이스 자격 증명)를 **`serverless.yml`** 또는 코드에 직접 저장하면 리포지토리가 손상될 경우 노출될 수 있습니다.
 
-**추천되는** 방법은 serverless.com의 **`serverless.yml`** 파일에서 환경 변수를 저장하기 위해 `ssm` 또는 `s3` 공급자를 사용하는 것입니다. 이는 **배포 시 이러한 소스에서 환경 값을 가져오고** **lambdas** 환경 변수를 **값이 없는 텍스트로 구성**할 수 있게 해줍니다!
+**추천되는** 방법은 serverless.com의 **`serverless.yml`** 파일에서 환경 변수를 저장하는 것으로, `ssm` 또는 `s3` 공급자를 사용하여 **배포 시 이러한 소스에서 환경 값을 가져오고** **lambdas** 환경 변수를 **값이 없는 텍스트로 구성**하는 것입니다!
 
 > [!CAUTION]
-> 따라서 AWS 내에서 lambdas 구성을 읽을 수 있는 권한이 있는 사람은 **이 모든 환경 변수를 평문으로 접근할 수 있습니다!**
+> 따라서 AWS 내에서 lambdas 구성을 읽을 수 있는 권한이 있는 사람은 **모든 이러한 환경 변수를 평문으로 접근할 수 있습니다!**
 
 예를 들어, 다음 예제는 SSM을 사용하여 환경 변수를 가져옵니다:
 ```yaml
@@ -560,26 +560,26 @@ provider:
 environment:
 DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
 ```
-And even if this prevents hardcoding the environment variable value in the **`serverless.yml`** file, the value will be obtained at deployment time and will be **added in clear text inside the lambda environment variable**.
+그리고 이것이 **`serverless.yml`** 파일에 환경 변수 값을 하드코딩하는 것을 방지하더라도, 값은 배포 시점에 얻어지며 **람다 환경 변수 안에 평문으로 추가됩니다**.
 
 > [!TIP]
-> The recommended way to store environment variables using serveless.com would be to **store it in a AWS secret** and just store the secret name in the environment variable and the **lambda code should gather it**.
+> serveless.com을 사용하여 환경 변수를 저장하는 권장 방법은 **AWS 비밀에 저장**하고 비밀 이름만 환경 변수에 저장하며 **람다 코드가 이를 수집해야 합니다**.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Secrets Manager Integration:** Use services like **AWS Secrets Manager.**
-- **Encrypted Variables:** Leverage Serverless Framework’s encryption features for sensitive data.
-- **Access Controls:** Restrict access to secrets based on roles.
+- **비밀 관리자 통합:** **AWS Secrets Manager**와 같은 서비스를 사용합니다.
+- **암호화된 변수:** 민감한 데이터에 대해 Serverless Framework의 암호화 기능을 활용합니다.
+- **접근 제어:** 역할에 따라 비밀에 대한 접근을 제한합니다.
 
 ---
 
-### **Vulnerable Code and Dependencies**
+### **취약한 코드 및 종속성**
 
-Outdated or insecure dependencies can introduce vulnerabilities, while improper input handling may lead to code injection attacks.
+구식 또는 안전하지 않은 종속성은 취약점을 도입할 수 있으며, 부적절한 입력 처리는 코드 주입 공격으로 이어질 수 있습니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Dependency Management:** Regularly update dependencies and scan for vulnerabilities.
+- **종속성 관리:** 종속성을 정기적으로 업데이트하고 취약점을 스캔합니다.
 
 ```yaml
 plugins:
@@ -587,38 +587,38 @@ plugins:
 - serverless-plugin-snyk
 ```
 
-- **Input Validation:** Implement strict validation and sanitization of all inputs.
-- **Code Reviews:** Conduct thorough reviews to identify security flaws.
-- **Static Analysis:** Use tools to detect vulnerabilities in the codebase.
+- **입력 검증:** 모든 입력에 대해 엄격한 검증 및 정화를 구현합니다.
+- **코드 리뷰:** 보안 결함을 식별하기 위해 철저한 리뷰를 수행합니다.
+- **정적 분석:** 코드베이스의 취약점을 감지하기 위해 도구를 사용합니다.
 
 ---
 
-### **Inadequate Logging and Monitoring**
+### **부적절한 로깅 및 모니터링**
 
-Without proper logging and monitoring, malicious activities may go undetected, delaying incident response.
+적절한 로깅 및 모니터링이 없으면 악의적인 활동이 감지되지 않을 수 있으며, 사건 대응이 지연될 수 있습니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Centralized Logging:** Aggregate logs using services like **AWS CloudWatch** or **Datadog**.
+- **중앙 집중식 로깅:** **AWS CloudWatch** 또는 **Datadog**와 같은 서비스를 사용하여 로그를 집계합니다.
 
 ```yaml
 plugins:
 - serverless-plugin-datadog
 ```
 
-- **Enable Detailed Logging:** Capture essential information without exposing sensitive data.
-- **Set Up Alerts:** Configure alerts for suspicious activities or anomalies.
-- **Regular Monitoring:** Continuously monitor logs and metrics for potential security incidents.
+- **상세 로깅 활성화:** 민감한 데이터를 노출하지 않으면서 필수 정보를 캡처합니다.
+- **알림 설정:** 의심스러운 활동이나 이상 징후에 대한 알림을 구성합니다.
+- **정기 모니터링:** 잠재적인 보안 사건에 대해 로그 및 메트릭을 지속적으로 모니터링합니다.
 
 ---
 
-### **Insecure API Gateway Configurations**
+### **불안전한 API 게이트웨이 구성**
 
-Open or improperly secured APIs can be exploited for unauthorized access, Denial of Service (DoS) attacks, or cross-site attacks.
+열려 있거나 부적절하게 보호된 API는 무단 접근, 서비스 거부(DoS) 공격 또는 교차 사이트 공격에 악용될 수 있습니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Authentication and Authorization:** Implement robust mechanisms like OAuth, API keys, or JWT.
+- **인증 및 권한 부여:** OAuth, API 키 또는 JWT와 같은 강력한 메커니즘을 구현합니다.
 
 ```yaml
 functions:
@@ -631,7 +631,7 @@ method: get
 authorizer: aws_iam
 ```
 
-- **Rate Limiting and Throttling:** Prevent abuse by limiting request rates.
+- **요청 속도 제한 및 조절:** 요청 속도를 제한하여 남용을 방지합니다.
 
 ```yaml
 provider:
@@ -641,7 +641,7 @@ burstLimit: 200
 rateLimit: 100
 ```
 
-- **Secure CORS Configuration:** Restrict allowed origins, methods, and headers.
+- **안전한 CORS 구성:** 허용된 출처, 메서드 및 헤더를 제한합니다.
 
 ```yaml
 functions:
@@ -657,19 +657,19 @@ headers:
 - Content-Type
 ```
 
-- **Use Web Application Firewalls (WAF):** Filter and monitor HTTP requests for malicious patterns.
+- **웹 애플리케이션 방화벽(WAF) 사용:** 악의적인 패턴에 대해 HTTP 요청을 필터링하고 모니터링합니다.
 
 ---
 
-### **Insufficient Function Isolation**
+### **불충분한 함수 격리**
 
-Shared resources and inadequate isolation can lead to privilege escalations or unintended interactions between functions.
+공유 리소스와 불충분한 격리는 권한 상승 또는 함수 간의 의도하지 않은 상호작용을 초래할 수 있습니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Isolate Functions:** Assign distinct resources and IAM roles to ensure independent operation.
-- **Resource Partitioning:** Use separate databases or storage buckets for different functions.
-- **Use VPCs:** Deploy functions within Virtual Private Clouds for enhanced network isolation.
+- **함수 격리:** 독립적인 작동을 보장하기 위해 고유한 리소스 및 IAM 역할을 할당합니다.
+- **리소스 분할:** 서로 다른 함수에 대해 별도의 데이터베이스 또는 저장소 버킷을 사용합니다.
+- **VPC 사용:** 향상된 네트워크 격리를 위해 가상 사설 클라우드 내에서 함수를 배포합니다.
 
 ```yaml
 provider:
@@ -680,17 +680,17 @@ subnetIds:
 - subnet-xxxxxx
 ```
 
-- **Limit Function Permissions:** Ensure functions cannot access or interfere with each other’s resources unless explicitly required.
+- **함수 권한 제한:** 함수가 명시적으로 요구되지 않는 한 서로의 리소스에 접근하거나 간섭할 수 없도록 합니다.
 
 ---
 
-### **Inadequate Data Protection**
+### **불충분한 데이터 보호**
 
-Unencrypted data at rest or in transit can be exposed, leading to data breaches or tampering.
+정지 상태 또는 전송 중 암호화되지 않은 데이터는 노출될 수 있으며, 데이터 유출 또는 변조로 이어질 수 있습니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Encrypt Data at Rest:** Utilize cloud service encryption features.
+- **정지 상태 데이터 암호화:** 클라우드 서비스 암호화 기능을 활용합니다.
 
 ```yaml
 resources:
@@ -702,25 +702,25 @@ SSESpecification:
 SSEEnabled: true
 ```
 
-- **Encrypt Data in Transit:** Use HTTPS/TLS for all data transmissions.
-- **Secure API Communication:** Enforce encryption protocols and validate certificates.
-- **Manage Encryption Keys Securely:** Use managed key services and rotate keys regularly.
+- **전송 중 데이터 암호화:** 모든 데이터 전송에 대해 HTTPS/TLS를 사용합니다.
+- **API 통신 보안:** 암호화 프로토콜을 시행하고 인증서를 검증합니다.
+- **암호화 키를 안전하게 관리:** 관리형 키 서비스를 사용하고 키를 정기적으로 교체합니다.
 
 ---
 
-### **Lack of Proper Error Handling**
+### **적절한 오류 처리 부족**
 
-Detailed error messages can leak sensitive information about the infrastructure or codebase, while unhandled exceptions may lead to application crashes.
+상세한 오류 메시지는 인프라 또는 코드베이스에 대한 민감한 정보를 유출할 수 있으며, 처리되지 않은 예외는 애플리케이션 충돌로 이어질 수 있습니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Generic Error Messages:** Avoid exposing internal details in error responses.
+- **일반 오류 메시지:** 오류 응답에서 내부 세부 정보를 노출하지 않도록 합니다.
 
 ```javascript
-javascriptCopy code// Example in Node.js
+javascriptCopy code// Node.js의 예
 exports.hello = async (event) => {
 try {
-// Function logic
+// 함수 로직
 } catch (error) {
 console.error(error);
 return {
@@ -731,78 +731,78 @@ body: JSON.stringify({ message: 'Internal Server Error' }),
 };
 ```
 
-- **Centralized Error Handling:** Manage and sanitize errors consistently across all functions.
-- **Monitor and Log Errors:** Track and analyze errors internally without exposing details to end-users.
+- **중앙 집중식 오류 처리:** 모든 함수에서 오류를 일관되게 관리하고 정화합니다.
+- **오류 모니터링 및 로깅:** 세부 정보를 최종 사용자에게 노출하지 않고 내부적으로 오류를 추적하고 분석합니다.
 
 ---
 
-### **Insecure Deployment Practices**
+### **불안전한 배포 관행**
 
-Exposed deployment configurations or unauthorized access to CI/CD pipelines can lead to malicious code deployments or misconfigurations.
+노출된 배포 구성 또는 CI/CD 파이프라인에 대한 무단 접근은 악의적인 코드 배포 또는 잘못된 구성을 초래할 수 있습니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Secure CI/CD Pipelines:** Implement strict access controls, multi-factor authentication (MFA), and regular audits.
-- **Store Configuration Securely:** Keep deployment files free from hardcoded secrets and sensitive data.
-- **Use Infrastructure as Code (IaC) Security Tools:** Employ tools like **Checkov** or **Terraform Sentinel** to enforce security policies.
-- **Immutable Deployments:** Prevent unauthorized changes post-deployment by adopting immutable infrastructure practices.
+- **CI/CD 파이프라인 보안:** 엄격한 접근 제어, 다단계 인증(MFA) 및 정기 감사 구현합니다.
+- **구성을 안전하게 저장:** 배포 파일에서 하드코딩된 비밀 및 민감한 데이터를 제거합니다.
+- **코드로서의 인프라(IaC) 보안 도구 사용:** **Checkov** 또는 **Terraform Sentinel**과 같은 도구를 사용하여 보안 정책을 시행합니다.
+- **불변 배포:** 불변 인프라 관행을 채택하여 배포 후 무단 변경을 방지합니다.
 
 ---
 
-### **Vulnerabilities in Plugins and Extensions**
+### **플러그인 및 확장 프로그램의 취약점**
 
-Using unvetted or malicious third-party plugins can introduce vulnerabilities into your serverless applications.
+검증되지 않거나 악의적인 제3자 플러그인을 사용하면 서버리스 애플리케이션에 취약점을 도입할 수 있습니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Vet Plugins Thoroughly:** Assess the security of plugins before integration, favoring those from reputable sources.
-- **Limit Plugin Usage:** Use only necessary plugins to minimize the attack surface.
-- **Monitor Plugin Updates:** Keep plugins updated to benefit from security patches.
-- **Isolate Plugin Environments:** Run plugins in isolated environments to contain potential compromises.
+- **플러그인 철저 검토:** 통합 전에 플러그인의 보안을 평가하고 평판이 좋은 출처의 플러그인을 선호합니다.
+- **플러그인 사용 제한:** 공격 표면을 최소화하기 위해 필요한 플러그인만 사용합니다.
+- **플러그인 업데이트 모니터링:** 보안 패치를 활용하기 위해 플러그인을 최신 상태로 유지합니다.
+- **플러그인 환경 격리:** 잠재적인 손상을 방지하기 위해 플러그인을 격리된 환경에서 실행합니다.
 
 ---
 
-### **Exposure of Sensitive Endpoints**
+### **민감한 엔드포인트 노출**
 
-Publicly accessible functions or unrestricted APIs can be exploited for unauthorized operations.
+공개적으로 접근 가능한 함수 또는 제한 없는 API는 무단 작업에 악용될 수 있습니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Restrict Function Access:** Use VPCs, security groups, and firewall rules to limit access to trusted sources.
-- **Implement Robust Authentication:** Ensure all exposed endpoints require proper authentication and authorization.
-- **Use API Gateways Securely:** Configure API Gateways to enforce security policies, including input validation and rate limiting.
-- **Disable Unused Endpoints:** Regularly review and disable any endpoints that are no longer in use.
+- **함수 접근 제한:** VPC, 보안 그룹 및 방화벽 규칙을 사용하여 신뢰할 수 있는 출처로의 접근을 제한합니다.
+- **강력한 인증 구현:** 모든 노출된 엔드포인트가 적절한 인증 및 권한 부여를 요구하도록 합니다.
+- **API 게이트웨이를 안전하게 사용:** API 게이트웨이를 구성하여 입력 검증 및 속도 제한을 포함한 보안 정책을 시행합니다.
+- **사용하지 않는 엔드포인트 비활성화:** 더 이상 사용하지 않는 엔드포인트를 정기적으로 검토하고 비활성화합니다.
 
 ---
 
-### **Excessive Permissions for Team Members and External Collaborators**
+### **팀원 및 외부 협력자에 대한 과도한 권한**
 
-Granting excessive permissions to team members and external collaborators can lead to unauthorized access, data breaches, and misuse of resources. This risk is heightened in environments where multiple individuals have varying levels of access, increasing the attack surface and potential for insider threats.
+팀원 및 외부 협력자에게 과도한 권한을 부여하면 무단 접근, 데이터 유출 및 리소스 남용으로 이어질 수 있습니다. 이 위험은 여러 개인이 다양한 수준의 접근 권한을 가진 환경에서 더욱 커지며, 공격 표면과 내부 위협의 가능성을 증가시킵니다.
 
-#### **Mitigation Strategies**
+#### **완화 전략**
 
-- **Principle of Least Privilege:** Ensure that team members and collaborators have only the permissions necessary to perform their tasks.
+- **최소 권한 원칙:** 팀원 및 협력자가 작업을 수행하는 데 필요한 권한만 가지도록 합니다.
 
 ---
 
-### **Access Keys and License Keys Security**
+### **액세스 키 및 라이센스 키 보안**
 
-**Access Keys** and **License Keys** are critical credentials used to authenticate and authorize interactions with the Serverless Framework CLI.
+**액세스 키** 및 **라이센스 키**는 Serverless Framework CLI와의 상호작용을 인증하고 권한을 부여하는 데 사용되는 중요한 자격 증명입니다.
 
-- **License Keys:** 그들은 Serverless Framework Version 4에 대한 접근을 인증하는 데 필요한 고유 식별자입니다. CLI를 통해 로그인할 수 있습니다.
-- **Access Keys:** Serverless Framework CLI가 Serverless Framework Dashboard와 인증하는 데 사용하는 자격 증명입니다. `serverless` cli로 로그인할 때 액세스 키가 **생성되어 노트북에 저장됩니다**. 또한 `SERVERLESS_ACCESS_KEY`라는 환경 변수로 설정할 수 있습니다.
+- **라이센스 키:** CLI를 통해 로그인할 수 있도록 하는 Serverless Framework 버전 4에 대한 인증에 필요한 고유 식별자입니다.
+- **액세스 키:** Serverless Framework Dashboard와 인증하기 위해 Serverless Framework CLI가 사용하는 자격 증명입니다. `serverless` cli로 로그인할 때 액세스 키가 **생성되어 노트북에 저장됩니다**. 또한 `SERVERLESS_ACCESS_KEY`라는 환경 변수로 설정할 수 있습니다.
 
-#### **Security Risks**
+#### **보안 위험**
 
-1. **Exposure Through Code Repositories:**
-- Access Keys 및 License Keys를 하드코딩하거나 실수로 버전 관리 시스템에 커밋하면 무단 접근이 발생할 수 있습니다.
-2. **Insecure Storage:**
-- 적절한 암호화 없이 환경 변수나 구성 파일에 평문으로 키를 저장하면 유출 가능성이 높아집니다.
-3. **Improper Distribution:**
-- 안전하지 않은 채널(예: 이메일, 채팅)을 통해 키를 공유하면 악의적인 행위자에 의해 가로채질 수 있습니다.
-4. **Lack of Rotation:**
+1. **코드 리포지토리를 통한 노출:**
+- 액세스 키 및 라이센스 키를 하드코딩하거나 실수로 버전 관리 시스템에 커밋하면 무단 접근이 발생할 수 있습니다.
+2. **안전하지 않은 저장:**
+- 적절한 암호화 없이 환경 변수나 구성 파일 내에 평문으로 키를 저장하면 유출 가능성이 높아집니다.
+3. **부적절한 배포:**
+- 안전하지 않은 채널(예: 이메일, 채팅)을 통해 키를 공유하면 악의적인 행위자에게 가로채질 수 있습니다.
+4. **회전 부족:**
 - 키를 정기적으로 회전하지 않으면 키가 손상된 경우 노출 기간이 연장됩니다.
-5. **Excessive Permissions:**
+5. **과도한 권한:**
 - 광범위한 권한을 가진 키는 여러 리소스에서 무단 작업을 수행하는 데 악용될 수 있습니다.
 
 {{#include ../banners/hacktricks-training.md}}