# Sécurité de Serverless.com {{#include ../banners/hacktricks-training.md}} ## Informations de base ### Organisation Une **Organisation** est l'entité de plus haut niveau au sein de l'écosystème Serverless Framework. Elle représente un **groupe collectif**, tel qu'une entreprise, un département ou toute grande entité, qui englobe plusieurs projets, équipes et applications. ### Équipe L'**Équipe** est constituée des utilisateurs ayant accès à l'organisation. Les équipes aident à organiser les membres en fonction des rôles. Les **`Collaborateurs`** peuvent voir et déployer des applications existantes, tandis que les **`Admins`** peuvent créer de nouvelles applications et gérer les paramètres de l'organisation. ### Application Une **App** est un regroupement logique de services liés au sein d'une Organisation. Elle représente une application complète composée de plusieurs services serverless qui travaillent ensemble pour fournir une fonctionnalité cohérente. ### **Services** Un **Service** est le composant central d'une application Serverless. Il représente l'ensemble de votre projet serverless, englobant toutes les fonctions, configurations et ressources nécessaires. Il est généralement défini dans un fichier `serverless.yml`, un service inclut des métadonnées telles que le nom du service, les configurations du fournisseur, les fonctions, les événements, les ressources, les plugins et les variables personnalisées. ```yaml service: my-service provider: name: aws runtime: nodejs14.x functions: hello: handler: handler.hello ```
Fonction Une **Fonction** représente une seule fonction sans serveur, comme une fonction AWS Lambda. Elle contient le code qui s'exécute en réponse à des événements. Elle est définie sous la section `functions` dans `serverless.yml`, spécifiant le gestionnaire, l'environnement d'exécution, les événements, les variables d'environnement et d'autres paramètres. ```yaml functions: hello: handler: handler.hello events: - http: path: hello method: get ```
Événement **Les événements** sont des déclencheurs qui invoquent vos fonctions sans serveur. Ils définissent comment et quand une fonction doit être exécutée. Les types d'événements courants incluent les requêtes HTTP, les événements planifiés (tâches cron), les événements de base de données, les téléchargements de fichiers, et plus encore. ```yaml functions: hello: handler: handler.hello events: - http: path: hello method: get - schedule: rate: rate(10 minutes) ```
Ressource **Ressources** vous permettent de définir des ressources cloud supplémentaires dont votre service dépend, telles que des bases de données, des buckets de stockage ou des rôles IAM. Elles sont spécifiées sous la section `resources`, souvent en utilisant la syntaxe CloudFormation pour AWS. ```yaml resources: Resources: MyDynamoDBTable: Type: AWS::DynamoDB::Table Properties: TableName: my-table AttributeDefinitions: - AttributeName: id AttributeType: S KeySchema: - AttributeName: id KeyType: HASH ProvisionedThroughput: ReadCapacityUnits: 1 WriteCapacityUnits: 1 ```
Fournisseur L'objet **Fournisseur** spécifie le fournisseur de services cloud (par exemple, AWS, Azure, Google Cloud) et contient des paramètres de configuration pertinents pour ce fournisseur. Il inclut des détails comme l'environnement d'exécution, la région, l'étape et les identifiants. ```yaml yamlCopy codeprovider: name: aws runtime: nodejs14.x region: us-east-1 stage: dev ```
Étape et Région L'étape représente différents environnements (par exemple, développement, préproduction, production) où votre service peut être déployé. Elle permet des configurations et des déploiements spécifiques à l'environnement. ```yaml provider: stage: dev ``` La région spécifie la région géographique où vos ressources seront déployées. C'est important pour des considérations de latence, de conformité et de disponibilité. ```yaml provider: region: us-west-2 ```
Plugins **Plugins** étendent la fonctionnalité du Serverless Framework en ajoutant de nouvelles fonctionnalités ou en s'intégrant à d'autres outils et services. Ils sont définis dans la section `plugins` et installés via npm. ```yaml plugins: - serverless-offline - serverless-webpack ```
Couches **Couches** vous permettent d'emballer et de gérer le code partagé ou les dépendances séparément de vos fonctions. Cela favorise la réutilisabilité et réduit la taille des packages de déploiement. Elles sont définies dans la section `layers` et référencées par les fonctions. ```yaml layers: commonLibs: path: layer-common functions: hello: handler: handler.hello layers: - { Ref: CommonLibsLambdaLayer } ```
Variables et Variables Personnalisées **Variables** permettent une configuration dynamique en permettant l'utilisation de placeholders qui sont résolus au moment du déploiement. - **Syntaxe :** La syntaxe `${variable}` peut référencer des variables d'environnement, le contenu de fichiers ou d'autres paramètres de configuration. ```yaml functions: hello: handler: handler.hello environment: TABLE_NAME: ${self:custom.tableName} ``` * **Variables Personnalisées :** La section `custom` est utilisée pour définir des variables et des configurations spécifiques à l'utilisateur qui peuvent être réutilisées dans tout le `serverless.yml`. ```yaml custom: tableName: my-dynamodb-table stage: ${opt:stage, 'dev'} ```
Sorties **Sorties** définissent les valeurs qui sont retournées après qu'un service a été déployé, telles que les ARNs de ressources, les points de terminaison ou d'autres informations utiles. Elles sont spécifiées sous la section `outputs` et sont souvent utilisées pour exposer des informations à d'autres services ou pour un accès facile après le déploiement. ```yaml ¡outputs: ApiEndpoint: Description: "API Gateway endpoint URL" Value: Fn::Join: - "" - - "https://" - Ref: ApiGatewayRestApi - ".execute-api." - Ref: AWS::Region - ".amazonaws.com/" - Ref: AWS::Stage ```
Rôles et autorisations IAM **Rôles et autorisations IAM** définissent les informations d'identification de sécurité et les droits d'accès pour vos fonctions et autres ressources. Ils sont gérés sous les paramètres `provider` ou de fonction individuelle pour spécifier les autorisations nécessaires. ```yaml provider: [...] iam: role: statements: - Effect: 'Allow' Action: - 'dynamodb:PutItem' - 'dynamodb:Get*' - 'dynamodb:Scan*' - 'dynamodb:UpdateItem' - 'dynamodb:DeleteItem' Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} ```
Variables d'environnement **Les variables** vous permettent de transmettre des paramètres de configuration et des secrets à vos fonctions sans les coder en dur. Elles sont définies sous la section `environment` pour le fournisseur ou pour des fonctions individuelles. ```yaml provider: environment: STAGE: ${self:provider.stage} functions: hello: handler: handler.hello environment: TABLE_NAME: ${self:custom.tableName} ```
Dépendances **Dépendances** gèrent les bibliothèques et modules externes dont vos fonctions ont besoin. Elles sont généralement gérées via des gestionnaires de paquets comme npm ou pip, et regroupées avec votre package de déploiement à l'aide d'outils ou de plugins comme `serverless-webpack`. ```yaml plugins: - serverless-webpack ```
Hooks **Hooks** vous permettent d'exécuter des scripts ou des commandes personnalisés à des moments spécifiques du cycle de vie de déploiement. Ils sont définis à l'aide de plugins ou dans le `serverless.yml` pour effectuer des actions avant ou après les déploiements. ```yaml custom: hooks: before:deploy:deploy: echo "Starting deployment..." ```
### Tutoriel Ceci est un résumé du tutoriel officiel [**des docs**](https://www.serverless.com/framework/docs/tutorial) : 1. Créez un compte AWS (Serverless.com commence dans l'infrastructure AWS) 2. Créez un compte sur serverless.com 3. Créez une application : ```bash # Create temp folder for the tutorial mkdir /tmp/serverless-tutorial cd /tmp/serverless-tutorial # Install Serverless cli npm install -g serverless # Generate template serverless #Choose first one (AWS / Node.js / HTTP API) ## Indicate a name like "Tutorial" ## Login/Register ## Create A New App ## Indicate a name like "tutorialapp) ``` Cela aurait dû créer une **app** appelée `tutorialapp` que vous pouvez vérifier dans [serverless.com](serverless.com-security.md) et un dossier appelé `Tutorial` avec le fichier **`handler.js`** contenant du code JS avec un code `helloworld` et le fichier **`serverless.yml`** déclarant cette fonction : {{#tabs }} {{#tab name="handler.js" }} ```javascript exports.hello = async (event) => { return { statusCode: 200, body: JSON.stringify({ message: "Go Serverless v4! Your function executed successfully!", }), } } ``` {{#endtab }} {{#tab name="serverless.yml" }} ```yaml # "org" ensures this Service is used with the correct Serverless Framework Access Key. org: testing12342 # "app" enables Serverless Framework Dashboard features and sharing them with other Services. app: tutorialapp # "service" is the name of this project. This will also be added to your AWS resource names. service: Tutorial provider: name: aws runtime: nodejs20.x functions: hello: handler: handler.hello events: - httpApi: path: / method: get ``` {{#endtab }} {{#endtabs }} 4. Créez un fournisseur AWS en allant dans le **tableau de bord** à `https://app.serverless.com//settings/providers?providerId=new&provider=aws`. 1. Pour donner accès à `serverless.com` à AWS, il demandera d'exécuter une pile cloudformation en utilisant ce fichier de configuration (au moment de la rédaction) : [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml) 2. Ce modèle génère un rôle appelé **`SFRole-`** avec **`arn:aws:iam::aws:policy/AdministratorAccess`** sur le compte avec une identité de confiance qui permet au compte AWS de `Serverless.com` d'accéder au rôle.
Yaml roleTemplate ```yaml Description: This stack creates an IAM role that can be used by Serverless Framework for use in deployments. Resources: SFRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: AWS: arn:aws:iam::486128539022:root Action: - sts:AssumeRole Condition: StringEquals: sts:ExternalId: !Sub "ServerlessFramework-${OrgUid}" Path: / RoleName: !Ref RoleName ManagedPolicyArns: - arn:aws:iam::aws:policy/AdministratorAccess ReporterFunction: Type: Custom::ServerlessFrameworkReporter Properties: ServiceToken: "arn:aws:lambda:us-east-1:486128539022:function:sp-providers-stack-reporter-custom-resource-prod-tmen2ec" OrgUid: !Ref OrgUid RoleArn: !GetAtt SFRole.Arn Alias: !Ref Alias Outputs: SFRoleArn: Description: "ARN for the IAM Role used by Serverless Framework" Value: !GetAtt SFRole.Arn Parameters: OrgUid: Description: Serverless Framework Org Uid Type: String Alias: Description: Serverless Framework Provider Alias Type: String RoleName: Description: Serverless Framework Role Name Type: String ```
Relation de confiance ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::486128539022:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "ServerlessFramework-7bf7ddef-e1bf-43eb-a111-4d43e0894ccb" } } } ] } ```
5. Le tutoriel demande de créer le fichier `createCustomer.js` qui va essentiellement créer un nouveau point de terminaison API géré par le nouveau fichier JS et demande de modifier le fichier `serverless.yml` pour qu'il génère une **nouvelle table DynamoDB**, définisse une **variable d'environnement**, le rôle qui utilisera les lambdas générées. {{#tabs }} {{#tab name="createCustomer.js" }} ```javascript "use strict" const AWS = require("aws-sdk") module.exports.createCustomer = async (event) => { const body = JSON.parse(Buffer.from(event.body, "base64").toString()) const dynamoDb = new AWS.DynamoDB.DocumentClient() const putParams = { TableName: process.env.DYNAMODB_CUSTOMER_TABLE, Item: { primary_key: body.name, email: body.email, }, } await dynamoDb.put(putParams).promise() return { statusCode: 201, } } ``` {{#endtab }} {{#tab name="serverless.yml" }} ```yaml # "org" ensures this Service is used with the correct Serverless Framework Access Key. org: testing12342 # "app" enables Serverless Framework Dashboard features and sharing them with other Services. app: tutorialapp # "service" is the name of this project. This will also be added to your AWS resource names. service: Tutorial provider: name: aws runtime: nodejs20.x environment: DYNAMODB_CUSTOMER_TABLE: ${self:service}-customerTable-${sls:stage} iam: role: statements: - Effect: "Allow" Action: - "dynamodb:PutItem" - "dynamodb:Get*" - "dynamodb:Scan*" - "dynamodb:UpdateItem" - "dynamodb:DeleteItem" Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} functions: hello: handler: handler.hello events: - httpApi: path: / method: get createCustomer: handler: createCustomer.createCustomer events: - httpApi: path: / method: post resources: Resources: CustomerTable: Type: AWS::DynamoDB::Table Properties: AttributeDefinitions: - AttributeName: primary_key AttributeType: S BillingMode: PAY_PER_REQUEST KeySchema: - AttributeName: primary_key KeyType: HASH TableName: ${self:service}-customerTable-${sls:stage} ``` {{#endtab }} {{#endtabs }} 6. Déployez-le en exécutant **`serverless deploy`** 1. Le déploiement sera effectué via une CloudFormation Stack 2. Notez que les **lambdas sont exposées via API gateway** et non via des URLs directes 7. **Testez-le** 1. L'étape précédente affichera les **URLs** où vos fonctions lambda des points de terminaison API ont été déployées ## Revue de sécurité de Serverless.com ### **Rôles et permissions IAM mal configurés** Des rôles IAM trop permissifs peuvent accorder un accès non autorisé aux ressources cloud, entraînant des violations de données ou une manipulation des ressources. Lorsqu'aucune permission n'est spécifiée pour une fonction Lambda, un rôle avec des permissions uniquement pour générer des journaux sera créé, comme :
Permissions minimales de lambda ```json { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:CreateLogGroup", "logs:TagResource" ], "Resource": [ "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/jito-cranker-scripts-dev*:*" ], "Effect": "Allow" }, { "Action": ["logs:PutLogEvents"], "Resource": [ "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/jito-cranker-scripts-dev*:*:*" ], "Effect": "Allow" } ] } ```
#### **Stratégies d'atténuation** - **Principe du Moindre Privilège :** Attribuez uniquement les autorisations nécessaires à chaque fonction. ```yaml provider: [...] iam: role: statements: - Effect: 'Allow' Action: - 'dynamodb:PutItem' - 'dynamodb:Get*' - 'dynamodb:Scan*' - 'dynamodb:UpdateItem' - 'dynamodb:DeleteItem' Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} ``` - **Utiliser des Rôles Séparés :** Différenciez les rôles en fonction des exigences de la fonction. --- ### **Secrets Insecure et Gestion de Configuration** Stocker des informations sensibles (par exemple, des clés API, des identifiants de base de données) directement dans **`serverless.yml`** ou le code peut entraîner une exposition si les dépôts sont compromis. La manière **recommandée** de stocker des variables d'environnement dans le fichier **`serverless.yml`** de serverless.com (au moment de la rédaction) est d'utiliser les fournisseurs `ssm` ou `s3`, ce qui permet d'obtenir les **valeurs d'environnement de ces sources au moment du déploiement** et de **configurer** les **variables d'environnement des lambdas** avec le **texte clair des valeurs** ! > [!CAUTION] > Par conséquent, toute personne ayant des autorisations pour lire la configuration des lambdas dans AWS pourra **accéder à toutes ces variables d'environnement en texte clair !** Par exemple, l'exemple suivant utilisera SSM pour obtenir une variable d'environnement : ```yaml provider: environment: DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true} ``` Et même si cela empêche de coder en dur la valeur de la variable d'environnement dans le **`serverless.yml`**, la valeur sera obtenue au moment du déploiement et sera **ajoutée en texte clair à l'intérieur de la variable d'environnement lambda**. > [!TIP] > La manière recommandée de stocker des variables d'environnement en utilisant serveless.com serait de **les stocker dans un secret AWS** et de simplement stocker le nom du secret dans la variable d'environnement et le **code lambda devrait le récupérer**. #### **Stratégies d'atténuation** - **Intégration avec Secrets Manager :** Utilisez des services comme **AWS Secrets Manager.** - **Variables Chiffrées :** Profitez des fonctionnalités de chiffrement du Serverless Framework pour les données sensibles. - **Contrôles d'Accès :** Restreindre l'accès aux secrets en fonction des rôles. --- ### **Code et Dépendances Vulnérables** Des dépendances obsolètes ou non sécurisées peuvent introduire des vulnérabilités, tandis qu'un traitement incorrect des entrées peut entraîner des attaques par injection de code. #### **Stratégies d'atténuation** - **Gestion des Dépendances :** Mettez régulièrement à jour les dépendances et scannez les vulnérabilités. ```yaml plugins: - serverless-webpack - serverless-plugin-snyk ``` - **Validation des Entrées :** Implémentez une validation stricte et une désinfection de toutes les entrées. - **Revue de Code :** Effectuez des revues approfondies pour identifier les failles de sécurité. - **Analyse Statique :** Utilisez des outils pour détecter les vulnérabilités dans le code. --- ### **Journalisation et Surveillance Inadéquates** Sans une journalisation et une surveillance appropriées, les activités malveillantes peuvent passer inaperçues, retardant la réponse aux incidents. #### **Stratégies d'atténuation** - **Journalisation Centralisée :** Agrégez les journaux en utilisant des services comme **AWS CloudWatch** ou **Datadog**. ```yaml plugins: - serverless-plugin-datadog ``` - **Activer la Journalisation Détailée :** Capturez des informations essentielles sans exposer de données sensibles. - **Configurer des Alertes :** Configurez des alertes pour des activités ou des anomalies suspectes. - **Surveillance Régulière :** Surveillez en continu les journaux et les métriques pour des incidents de sécurité potentiels. --- ### **Configurations Insecure de l'API Gateway** Des API ouvertes ou mal sécurisées peuvent être exploitées pour un accès non autorisé, des attaques par déni de service (DoS) ou des attaques intersites. #### **Stratégies d'atténuation** - **Authentification et Autorisation :** Implémentez des mécanismes robustes comme OAuth, des clés API ou JWT. ```yaml functions: hello: handler: handler.hello events: - http: path: hello method: get authorizer: aws_iam ``` - **Limitation de Taux et Throttling :** Prévenir les abus en limitant les taux de requêtes. ```yaml provider: apiGateway: throttle: burstLimit: 200 rateLimit: 100 ``` - **Configuration CORS Sécurisée :** Restreindre les origines, méthodes et en-têtes autorisés. ```yaml functions: hello: handler: handler.hello events: - http: path: hello method: get cors: origin: https://yourdomain.com headers: - Content-Type ``` - **Utiliser des Pare-feux d'Applications Web (WAF) :** Filtrer et surveiller les requêtes HTTP pour des motifs malveillants. --- ### **Isolation de Fonction Insuffisante** Des ressources partagées et une isolation inadéquate peuvent entraîner des élévations de privilèges ou des interactions non intentionnelles entre les fonctions. #### **Stratégies d'atténuation** - **Isoler les Fonctions :** Assignez des ressources distinctes et des rôles IAM pour garantir un fonctionnement indépendant. - **Partitionnement des Ressources :** Utilisez des bases de données ou des seaux de stockage séparés pour différentes fonctions. - **Utiliser des VPC :** Déployez des fonctions au sein de Clouds Privés Virtuels pour une isolation réseau améliorée. ```yaml provider: vpc: securityGroupIds: - sg-xxxxxxxx subnetIds: - subnet-xxxxxx ``` - **Limiter les Permissions des Fonctions :** Assurez-vous que les fonctions ne peuvent pas accéder ou interférer avec les ressources des autres, sauf si cela est explicitement requis. --- ### **Protection des Données Inadéquate** Des données non chiffrées au repos ou en transit peuvent être exposées, entraînant des violations de données ou des falsifications. #### **Stratégies d'atténuation** - **Chiffrer les Données au Repos :** Utilisez les fonctionnalités de chiffrement des services cloud. ```yaml resources: Resources: MyDynamoDBTable: Type: AWS::DynamoDB::Table Properties: SSESpecification: SSEEnabled: true ``` - **Chiffrer les Données en Transit :** Utilisez HTTPS/TLS pour toutes les transmissions de données. - **Sécuriser la Communication API :** Appliquez des protocoles de chiffrement et validez les certificats. - **Gérer les Clés de Chiffrement de Manière Sécurisée :** Utilisez des services de clés gérés et faites tourner les clés régulièrement. --- ### **Manque de Gestion d'Erreurs Appropriée** Des messages d'erreur détaillés peuvent révéler des informations sensibles sur l'infrastructure ou le code, tandis que des exceptions non gérées peuvent entraîner des plantages d'application. #### **Stratégies d'atténuation** - **Messages d'Erreur Généraux :** Évitez d'exposer des détails internes dans les réponses d'erreur. ```javascript javascriptCopy code// Exemple en Node.js exports.hello = async (event) => { try { // Logique de la fonction } catch (error) { console.error(error); return { statusCode: 500, body: JSON.stringify({ message: 'Erreur Interne du Serveur' }), }; } }; ``` - **Gestion Centralisée des Erreurs :** Gérez et désinfectez les erreurs de manière cohérente à travers toutes les fonctions. - **Surveiller et Journaliser les Erreurs :** Suivez et analysez les erreurs en interne sans exposer les détails aux utilisateurs finaux. --- ### **Pratiques de Déploiement Insecure** Des configurations de déploiement exposées ou un accès non autorisé aux pipelines CI/CD peuvent entraîner des déploiements de code malveillant ou des erreurs de configuration. #### **Stratégies d'atténuation** - **Sécuriser les Pipelines CI/CD :** Mettez en œuvre des contrôles d'accès stricts, une authentification multi-facteurs (MFA) et des audits réguliers. - **Stocker la Configuration de Manière Sécurisée :** Gardez les fichiers de déploiement exempts de secrets codés en dur et de données sensibles. - **Utiliser des Outils de Sécurité pour l'Infrastructure as Code (IaC) :** Employez des outils comme **Checkov** ou **Terraform Sentinel** pour appliquer des politiques de sécurité. - **Déploiements Immutables :** Empêchez les modifications non autorisées après le déploiement en adoptant des pratiques d'infrastructure immuable. --- ### **Vulnérabilités dans les Plugins et Extensions** L'utilisation de plugins tiers non vérifiés ou malveillants peut introduire des vulnérabilités dans vos applications serverless. #### **Stratégies d'atténuation** - **Vérifiez les Plugins en Profondeur :** Évaluez la sécurité des plugins avant l'intégration, en privilégiant ceux provenant de sources réputées. - **Limiter l'Utilisation des Plugins :** Utilisez uniquement les plugins nécessaires pour minimiser la surface d'attaque. - **Surveiller les Mises à Jour des Plugins :** Gardez les plugins à jour pour bénéficier des correctifs de sécurité. - **Isoler les Environnements de Plugins :** Exécutez les plugins dans des environnements isolés pour contenir d'éventuels compromis. --- ### **Exposition de Points de Terminaison Sensibles** Des fonctions accessibles au public ou des API non restreintes peuvent être exploitées pour des opérations non autorisées. #### **Stratégies d'atténuation** - **Restreindre l'Accès aux Fonctions :** Utilisez des VPC, des groupes de sécurité et des règles de pare-feu pour limiter l'accès aux sources de confiance. - **Implémenter une Authentification Robuste :** Assurez-vous que tous les points de terminaison exposés nécessitent une authentification et une autorisation appropriées. - **Utiliser les API Gateways de Manière Sécurisée :** Configurez les API Gateways pour appliquer des politiques de sécurité, y compris la validation des entrées et la limitation de taux. - **Désactiver les Points de Terminaison Inutilisés :** Passez régulièrement en revue et désactivez tous les points de terminaison qui ne sont plus utilisés. --- ### **Permissions Excessives pour les Membres de l'Équipe et les Collaborateurs Externes** Accorder des permissions excessives aux membres de l'équipe et aux collaborateurs externes peut entraîner un accès non autorisé, des violations de données et un abus de ressources. Ce risque est accru dans les environnements où plusieurs individus ont des niveaux d'accès variés, augmentant la surface d'attaque et le potentiel de menaces internes. #### **Stratégies d'atténuation** - **Principe du Moins de Privilèges :** Assurez-vous que les membres de l'équipe et les collaborateurs n'ont que les permissions nécessaires pour effectuer leurs tâches. --- ### **Sécurité des Clés d'Accès et des Clés de Licence** **Clés d'Accès** et **Clés de Licence** sont des identifiants critiques utilisés pour authentifier et autoriser les interactions avec le CLI de Serverless Framework. - **Clés de Licence :** Ce sont des identifiants uniques requis pour authentifier l'accès à Serverless Framework Version 4 qui permet de se connecter via CLI. - **Clés d'Accès :** Ce sont des identifiants qui permettent au CLI de Serverless Framework de s'authentifier avec le Dashboard de Serverless Framework. Lors de la connexion avec le cli `serverless`, une clé d'accès sera **générée et stockée sur l'ordinateur portable**. Vous pouvez également la définir comme une variable d'environnement nommée `SERVERLESS_ACCESS_KEY`. #### **Risques de Sécurité** 1. **Exposition par le biais de Dépôts de Code :** - Coder en dur ou commettre accidentellement des Clés d'Accès et des Clés de Licence dans des systèmes de contrôle de version peut entraîner un accès non autorisé. 2. **Stockage Insecure :** - Stocker des clés en texte clair dans des variables d'environnement ou des fichiers de configuration sans chiffrement approprié augmente la probabilité de fuite. 3. **Distribution Inappropriée :** - Partager des clés par des canaux non sécurisés (par exemple, email, chat) peut entraîner une interception par des acteurs malveillants. 4. **Manque de Rotation :** - Ne pas faire tourner régulièrement les clés prolonge la période d'exposition si les clés sont compromises. 5. **Permissions Excessives :** - Des clés avec des permissions larges peuvent être exploitées pour effectuer des actions non autorisées sur plusieurs ressources. {{#include ../banners/hacktricks-training.md}}