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

This commit is contained in:
Translator
2025-01-02 01:49:00 +00:00
parent 210c27fffb
commit 5630d68e4e
226 changed files with 2238 additions and 2256 deletions

View File

@@ -2,23 +2,23 @@
{{#include ../banners/hacktricks-training.md}}
## Basic Information
## Основна інформація
### Organization
### Організація
**Організація** - це найвищий рівень сутності в екосистемі Serverless Framework. Вона представляє **колективну групу**, таку як компанія, відділ або будь-яка велика сутність, яка охоплює кілька проектів, команд і додатків.
**Організація** є найвищим рівнем сутності в екосистемі Serverless Framework. Вона представляє **колективну групу**, таку як компанія, відділ або будь-яка велика сутність, яка охоплює кілька проектів, команд і додатків.
### Team
### Команда
**Команда** - це користувачі з доступом всередині організації. Команди допомагають організувати учасників на основі ролей. **`Співпрацівники`** можуть переглядати та розгортати існуючі додатки, тоді як **`Адміністратори`** можуть створювати нові додатки та керувати налаштуваннями організації.
### Application
### Додаток
**Додаток** - це логічна група пов'язаних сервісів в організації. Він представляє собою повний додаток, що складається з кількох безсерверних сервісів, які працюють разом для забезпечення єдиної функціональності.
### **Services**
### **Сервіси**
**Сервіс** - це основний компонент безсерверного додатку. Він представляє ваш весь безсерверний проект, інкапсулюючи всі функції, конфігурації та ресурси, які потрібні. Зазвичай він визначається у файлі `serverless.yml`, сервіс включає метадані, такі як назва сервісу, конфігурації постачальника, функції, події, ресурси, плагіни та користувацькі змінні.
**Сервіс** є основним компонентом безсерверного додатку. Він представляє ваш весь безсерверний проект, інкапсулюючи всі функції, конфігурації та ресурси, які потрібні. Зазвичай він визначається у файлі `serverless.yml`, сервіс включає метадані, такі як назва сервісу, конфігурації постачальника, функції, події, ресурси, плагіни та користувацькі змінні.
```yaml
service: my-service
provider:
@@ -72,7 +72,7 @@ rate: rate(10 minutes)
**Ресурси** дозволяють вам визначити додаткові хмарні ресурси, від яких залежить ваша служба, такі як бази даних, сховища або ролі IAM.
Вони вказуються в секції `resources`, часто використовуючи синтаксис CloudFormation для AWS.
Вони вказуються в розділі `resources`, часто використовуючи синтаксис CloudFormation для AWS.
```yaml
resources:
Resources:
@@ -117,7 +117,7 @@ stage: dev
provider:
stage: dev
```
Регіон вказує географічний регіон, де будуть розгорнуті ваші ресурси. Це важливо для затримки, відповідності та доступності.
Регіон вказує географічний регіон, де будуть розгорнуті ваші ресурси. Це важливо для розгляду затримки, відповідності та доступності.
```yaml
provider:
region: us-west-2
@@ -140,7 +140,7 @@ plugins:
<summary>Шари</summary>
**Шари** дозволяють вам упакувати та керувати спільним кодом або залежностями окремо від ваших функцій. Це сприяє повторному використанню та зменшує розміри пакетів розгортання. Вони визначаються в секції `layers` і посилаються на функції.
**Шари** дозволяють вам упакувати та керувати спільним кодом або залежностями окремо від ваших функцій. Це сприяє повторному використанню та зменшує розміри пакетів розгортання. Вони визначені в секції `layers` і посилаються на функції.
```yaml
layers:
commonLibs:
@@ -202,9 +202,9 @@ Fn::Join:
<details>
<summary>IAM Ролі та Дозволи</summary>
<summary>Ролі та дозволи IAM</summary>
**IAM Ролі та Дозволи** визначають безпекові облікові дані та права доступу для ваших функцій та інших ресурсів. Вони керуються під `provider` або налаштуваннями окремих функцій для визначення необхідних дозволів.
**Ролі та дозволи IAM** визначають облікові дані безпеки та права доступу для ваших функцій та інших ресурсів. Вони керуються в рамках налаштувань `provider` або окремих функцій для визначення необхідних дозволів.
```yaml
provider:
[...]
@@ -226,7 +226,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
<summary>Змінні середовища</summary>
**Змінні** дозволяють передавати налаштування конфігурації та секрети вашим функціям без їх жорсткого кодування. Вони визначаються в секції `environment` для постачальника або окремих функцій.
**Змінні** дозволяють передавати налаштування конфігурації та секрети вашим функціям без їх жорсткого кодування. Вони визначені в секції `environment` для постачальника або окремих функцій.
```yaml
provider:
environment:
@@ -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), і папку під назвою `Tutorial` з файлом **`handler.js`**, що містить деякий JS код з кодом `helloworld`, та файлом **`serverless.yml`**, що оголошує цю функцію:
Це повинно було створити **додаток** під назвою `tutorialapp`, який ви можете перевірити на [serverless.com](serverless.com-security.md), а також папку під назвою `Tutorial` з файлом **`handler.js`**, що містить деякий JS код з кодом `helloworld`, і файлом **`serverless.yml`**, що оголошує цю функцію:
{{#tabs }}
{{#tab name="handler.js" }}
@@ -323,7 +323,7 @@ method: get
{{#endtab }}
{{#endtabs }}
4. Створіть постачальника AWS, перейшовши в **панель управління** за адресою `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
4. Створіть постачальника AWS, перейшовши в **dashboard** за адресою `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
1. Щоб надати `serverless.com` доступ до AWS, буде запропоновано запустити стек cloudformation, використовуючи цей конфігураційний файл (на момент написання): [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 отримати доступ до ролі.
@@ -399,7 +399,7 @@ Type: String
```
</details>
5. У навчальному посібнику пропонується створити файл `createCustomer.js`, який в основному створить нову точку доступу API, оброблену новим JS файлом, і пропонується змінити файл `serverless.yml`, щоб він генерував **нову таблицю DynamoDB**, визначав **змінну середовища**, роль, яка буде використовувати згенеровані лямбди.
5. У посібнику пропонується створити файл `createCustomer.js`, який в основному створить нову точку доступу API, оброблювану новим JS файлом, і пропонується змінити файл `serverless.yml`, щоб він генерував **нову таблицю DynamoDB**, визначив **змінну середовища**, роль, яка буде використовувати згенеровані lambdas.
{{#tabs }}
{{#tab name="createCustomer.js" }}
@@ -485,7 +485,7 @@ TableName: ${self:service}-customerTable-${sls:stage}
1. Розгортання буде виконано через CloudFormation Stack
2. Зверніть увагу, що **lambdas доступні через API gateway** і не через прямі URL
7. **Протестуйте це**
1. Попередній крок виведе **URLs**, де ваші API endpoints lambda функції були розгорнуті
1. Попередній крок виведе **URLs**, де ваші функції lambda API endpoints були розгорнуті
## Огляд безпеки Serverless.com
@@ -553,10 +553,10 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
Зберігання чутливої інформації (наприклад, API ключів, облікових даних бази даних) безпосередньо в **`serverless.yml`** або коді може призвести до витоку, якщо репозиторії будуть скомпрометовані.
**Рекомендований** спосіб зберігання змінних середовища у файлі **`serverless.yml`** від serverless.com (на момент написання цього тексту) - це використання постачальників `ssm` або `s3`, які дозволяють отримувати **значення середовища з цих джерел під час розгортання** та **конфігурувати** змінні середовища **lambdas** з **текстом без значень**!
**Рекомендований** спосіб зберігання змінних середовища у файлі **`serverless.yml`** з serverless.com (на момент написання цього матеріалу) - використовувати постачальників `ssm` або `s3`, що дозволяє отримувати **значення середовища з цих джерел під час розгортання** та **конфігурувати** змінні середовища **lambdas** з **текстом без значень**!
> [!CAUTION]
> Тому будь-хто з дозволами на читання конфігурації lambdas в AWS зможе **отримати доступ до всіх цих змінних середовища у відкритому тексті!**
> Тому будь-хто з дозволами на читання конфігурації lambdas всередині AWS зможе **отримати доступ до всіх цих змінних середовища у відкритому тексті!**
Наприклад, наступний приклад використовуватиме SSM для отримання змінної середовища:
```yaml
@@ -564,26 +564,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 **додано у відкритому тексті всередині змінної середовища lambda**.
І навіть якщо це запобігає жорсткому кодуванню значення змінної середовища у файлі **`serverless.yml`**, значення буде отримано під час розгортання і буде **додано у відкритому тексті всередині змінної середовища lambda**.
> [!TIP]
> The recommended way to store environment variables using serveless.com would be to **зберігати його в AWS secret** and just store the secret name in the environment variable and the **код lambda повинен його зібрати**.
> Рекомендований спосіб зберігання змінних середовища за допомогою serveless.com - це **зберігати їх у секреті AWS** і просто зберігати ім'я секрету у змінній середовища, а **код lambda повинен його зібрати**.
#### **Mitigation Strategies**
#### **Стратегії пом'якшення**
- **Secrets Manager Integration:** Use services like **AWS Secrets Manager.**
- **Encrypted Variables:** Leverage Serverless Frameworks encryption features for sensitive data.
- **Access Controls:** Restrict access to secrets based on roles.
- **Інтеграція з Secrets Manager:** Використовуйте сервіси, такі як **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:
@@ -591,38 +591,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 Gateway**
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:
@@ -635,7 +635,7 @@ method: get
authorizer: aws_iam
```
- **Rate Limiting and Throttling:** Prevent abuse by limiting request rates.
- **Обмеження швидкості та обмеження запитів:** Запобігайте зловживанням, обмежуючи швидкість запитів.
```yaml
provider:
@@ -645,7 +645,7 @@ burstLimit: 200
rateLimit: 100
```
- **Secure CORS Configuration:** Restrict allowed origins, methods, and headers.
- **Безпечна конфігурація CORS:** Обмежте дозволені джерела, методи та заголовки.
```yaml
functions:
@@ -661,19 +661,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:
@@ -684,17 +684,17 @@ subnetIds:
- subnet-xxxxxx
```
- **Limit Function Permissions:** Ensure functions cannot access or interfere with each others 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:
@@ -706,107 +706,107 @@ 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 {
statusCode: 500,
body: JSON.stringify({ message: 'Internal Server Error' }),
body: JSON.stringify({ message: 'Внутрішня помилка сервера' }),
};
}
};
```
- **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.
Використання неперевірених або шкідливих сторонніх плагінів може ввести вразливості у ваші безсерверні додатки.
#### **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 Gateway безпечно:** Налаштуйте API Gateway для забезпечення політик безпеки, включаючи валідацію введення та обмеження швидкості.
- **Вимкніть невикористовувані кінцеві точки:** Регулярно переглядайте та вимикайте будь-які кінцеві точки, які більше не використовуються.
---
### **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.
**Ключі доступу** та **ліцензійні ключі** є критично важливими обліковими даними, які використовуються для аутентифікації та авторизації взаємодій з CLI Serverless Framework.
- **License Keys:** Вони є унікальними ідентифікаторами, необхідними для аутентифікації доступу до Serverless Framework Version 4, що дозволяє входити через CLI.
- **Access Keys:** Облікові дані, які дозволяють CLI Serverless Framework аутентифікуватися з панеллю управління Serverless Framework. Коли ви входите за допомогою `serverless` cli, ключ доступу буде **згенеровано та збережено на ноутбуці**. Ви також можете встановити його як змінну середовища з назвою `SERVERLESS_ACCESS_KEY`.
- **Ліцензійні ключі:** Це унікальні ідентифікатори, необхідні для аутентифікації доступу до Serverless Framework версії 4, які дозволяють входити через CLI.
- **Ключі доступу:** Облікові дані, які дозволяють CLI Serverless Framework аутентифікуватися з панеллю управління Serverless Framework. Коли ви входите за допомогою `serverless` cli, ключ доступу буде **згенеровано та збережено на ноутбуці**. Ви також можете встановити його як змінну середовища з ім'ям `SERVERLESS_ACCESS_KEY`.
#### **Security Risks**
#### **Ризики безпеки**
1. **Exposure Through Code Repositories:**
- Hardcoding or accidentally committing Access Keys and License Keys to version control systems can lead to unauthorized access.
2. **Insecure Storage:**
- Storing keys in plaintext within environment variables or configuration files without proper encryption increases the likelihood of leakage.
3. **Improper Distribution:**
- Sharing keys through unsecured channels (e.g., email, chat) can result in interception by malicious actors.
4. **Lack of Rotation:**
- Not regularly rotating keys extends the exposure period if keys are compromised.
5. **Excessive Permissions:**
- Keys with broad permissions can be exploited to perform unauthorized actions across multiple resources.
1. **Витік через репозиторії коду:**
- Жорстке кодування або випадкове комітування ключів доступу та ліцензійних ключів у системи контролю версій може призвести до несанкціонованого доступу.
2. **Небезпечне зберігання:**
- Зберігання ключів у відкритому тексті в змінних середовища або конфігураційних файлах без належного шифрування підвищує ймовірність витоку.
3. **Неправильне розповсюдження:**
- Обмін ключами через незахищені канали (наприклад, електронна пошта, чат) може призвести до перехоплення зловмисниками.
4. **Відсутність ротації:**
- Нерегулярна ротація ключів подовжує період експозиції, якщо ключі скомпрометовані.
5. **Надмірні дозволи:**
- Ключі з широкими дозволами можуть бути використані для виконання несанкціонованих дій на кількох ресурсах.
{{#include ../banners/hacktricks-training.md}}