Skip to content

Commit 2d102b3

Browse files
guacbotguacbot
authored
Translation Pipeline PR (DataDog#20719)
* adding translations * adding translations
1 parent 61b5a7b commit 2d102b3

File tree

2 files changed

+216
-0
lines changed

2 files changed

+216
-0
lines changed

‎content/fr/account_management/rbac/granular_access.md

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
---
2+
kind: documentation
3+
title: Contrôle d'accès granulaire
4+
---
5+
## Gérer l'accès à des ressources spécifiques
6+
7+
Certaines ressources vous permettent de restreindre l'accès à des ressources spécifiques en fonction des rôles, des [équipes][1] ou des utilisateurs.
8+
9+
Utilisez les différents principaux pour contrôler l'accès aux ressources au sein de votre organisation et encourager le partage des connaissances et la collaboration :
10+
- Utilisez des équipes pour accorder des accès à des groupes fonctionnels au sein de votre organisation. Vous pouvez, par exemple, rendre la modification d'un dashboard possible uniquement par l'équipe d'application qui en est propriétaire.
11+
- Utilisez des rôles pour accorder des accès à des types d'utilisateurs. Vous pouvez, par exemple, rendre la modification des moyens de paiement possible uniquement par les responsables de la facturation.
12+
- Accordez des accès à des utilisateurs individuels uniquement lorsque cela est nécessaire.
13+
14+
15+
| Ressources prenant en charge le contrôle d'accès granulaire | Accès par équipe | Accès par rôle | Accès par utilisateur / compte de service |
16+
|--------------------------------------------------|-------------------|-------------------|-------------------------------------|
17+
| [Dashboards][2] | {{< X >}} | {{< X >}} | {{< X >}} |
18+
| [Monitors][3] | | {{< X >}} | |
19+
| [Notebooks][4] | {{< X >}} | {{< X >}} | {{< X >}} |
20+
| [Règles de sécurité][5] | {{< X >}} | {{< X >}} | {{< X >}} |
21+
| [Service Level Objectives][6] | {{< X >}} | {{< X >}} | {{< X >}} |
22+
| [Tests Synthetic][7] | | {{< X >}} | |
23+
24+
### Obtenir l'accès à des ressources spécifiques
25+
26+
Un utilisateur disposant de l'autorisation `user_access_manage` peut obtenir l'accès en modification à toute ressource prenant en charge les restrictions basées sur une équipe, un rôle et un utilisateur/compte de service. Les ressources pour lesquelles il n'est possible de définir que des restrictions d'accès par rôle ne sont pas prises en charge. Pour obtenir l'accès à une ressource, cliquez sur le bouton **Gain Edit Access** dans la fenêtre de contrôle d'accès granulaire.
27+
28+
[1]: /fr/account_management/teams/
29+
[2]: /fr/dashboards/#permissions
30+
[3]: /fr/monitors/notify/#permissions
31+
[4]: /fr/notebooks/#limit-edit-access
32+
[5]: /fr/security/detection_rules/#limit-edit-access
33+
[6]: /fr/service_management/service_level_objectives/#permissions
34+
[7]: /fr/synthetics/browser_tests/#permissions

‎content/fr/security/threats/workload_security_rules.md

Lines changed: 182 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,182 @@
1+
---
2+
aliases:
3+
- /fr/security_platform/cloud_workload_security/workload_security_rules
4+
- /fr/security/cloud_workload_security/workload_security_rules
5+
further_reading:
6+
- link: /security/threats/setup
7+
tag: Documentation
8+
text: Configurer CSM Threats
9+
- link: /security/threats/agent_expressions
10+
tag: Documentation
11+
text: Expressions d'Agent
12+
- link: security/threats/backend
13+
tag: Documentation
14+
text: Événements CSM Threats
15+
- link: /security/notifications/variables/
16+
tag: Documentation
17+
text: En savoir plus sur les variables de notification de sécurité
18+
kind: documentation
19+
title: Gérer les règles de détection CSM Threats
20+
---
21+
22+
Lorsque Cloud Security Management Threats (CSM Threats) est activé, l'Agent Datadog surveille activement l'activité du système et procède à son évaluation sur la base d'un ensemble de règles prêtes à l'emploi en vue de détecter tout comportement suspect. CSM Threats se compose de deux éléments distincts : les [règles d'Agent](#regles-d-agent) et les [règles de détection](#regles-de-detection).
23+
24+
## Règles d'Agent
25+
26+
Les règles d'Agent se composent d'[expressions d'Agent](#expressions-d-agent) qui déterminent les activités recueillies par l'Agent. Un ensemble complet de règles d'Agent constitue une stratégie. Datadog fournit plusieurs [règles d'Agent prêtes à l'emploi][6] qui s'appuient sur la stratégie par défaut de l'Agent.
27+
28+
Lorsque la [configuration à distance][7] est activée, vous recevez automatiquement les nouvelles règles d'Agent pour CSM Threats et les mises à jour des règles existantes à mesure qu'elles sont publiées. Ces règles d'Agent fournies par Datadog sont utilisées dans les [règles de détection par défaut][1].
29+
30+
<div class="alert alert-info">La configuration à distance pour CSM Threats est en version bêta. Si vous avez des questions ou des commentaires, contactez l'<a href="/help">assistance Datadog</a>.</div>
31+
32+
### Expressions d'Agent
33+
34+
Les expressions d'Agent utilisent le [langage de sécurité (SECL) de Datadog][2] pour définir un comportement en fonction de l'activité au sein de vos hosts et conteneurs comme illustré dans les exemples suivants :
35+
36+
#### Détecter l'exécution de la commande `passwd`
37+
38+
Quelques attributs sont à prendre en compte pour détecter l'exécution de la commande `passwd`.
39+
40+
Dans la plupart des distributions Linux, l'utilitaire `passwd` est installé dans `/usr/bin/passwd`. Les événements d'exécution comprennent `exec`, `execve`, `fork` et d'autres appels système. Dans l'environnement CSM Threats, tous ces événements sont identifiés par le symbole `exec`.
41+
42+
L'expression de règle correspondant à tous ces attributs est `exec.file.path == "/usr/bin/passwd"`.
43+
44+
La règle de commande `passwd` est déjà présente dans la stratégie par défaut de l'Agent pour CSM Threats. Les expressions d'Agent peuvent toutefois être plus sophistiquées et définir des règles qui ciblent des ancêtres de processus ou contenir des wildcards pour augmenter la portée de la détection.
45+
46+
#### Détecter l'exécution de Bash par un processus PHP ou Nginx
47+
48+
Quelques attributs sont à prendre en compte pour détecter l'exécution de Bash par un processus PHP ou Nginx.
49+
50+
Dans la plupart des distributions Linux, Bash est installé dans `/usr/bin/bash`. Comme dans l'exemple précédent, incluez l'expression `exec.file.path == "/usr/bin/bash"` dans votre règle pour détecter son exécution. Cela permet à la règle de détecter l'exécution de Bash, que ce soit directement ou en tant que processus enfant d'un processus PHP ou Nginx.
51+
52+
Dans CSM Threats, l'attribut de nom de fichier d'un ancêtre de processus est identifié par le symbole `process.ancestors.file.name`. Pour vérifier si l'ancêtre est un processus Nginx, ajoutez `process.ancestors.file.name == "nginx"`. Comme PHP exécute plusieurs processus, utilisez un wildcard pour étendre la règle à tout processus présentant le préfixe PHP. Pour vérifier si l'ancêtre est un processus PHP, ajoutez donc `process.ancestors.file.name =~ "php*"`.
53+
54+
L'expression de règle correspondant à tous ces attributs est `exec.file.path == "/usr/bin/bash" && (process.ancestors.file.name == "nginx" || process.ancestors.file.name =~ "php*")`.
55+
56+
## Règles de détection
57+
58+
Les règles de détection sont exécutées dans le backend Datadog une fois les événements envoyés sous forme de logs. Ces derniers sont alors évalués en fonction des patterns d'événements décrits dans les [règles de détection][3]. Si le pattern correspond à une règle de détection, un [signal de sécurité][8] est généré. Datadog développe en permanence de nouvelles règles de détection, qui sont automatiquement importées dans votre compte.
59+
60+
## Créer des règles personnalisées
61+
62+
En plus des règles par défaut, vous pouvez créer des règles d'Agent et de détection personnalisées. Les règles d'Agent personnalisées sont déployées dans l'Agent par le biais d'une stratégie personnalisée distincte de celle par défaut. Cette stratégie personnalisée contient les règles d'Agent personnalisées ainsi que les [règles par défaut qui ont été désactivées](#desactiver-les-regles-d-agent-par-defaut).
63+
64+
### Définir la règle d'Agent
65+
66+
1. Sur la page [**Agent Configuration**][4], cliquez sur **New Rule**.
67+
2. Saisissez un nom et une description pour la règle.
68+
3. Définissez l'expression d'Agent dans le champ **Expression** en utilisant la syntaxe du langage de sécurité (SECL) de Datadog.
69+
70+
{{< img src="security/cws/workload_security_rules/define_agent_expression.png" alt="Ajout d'une règle dans le champ Expression" >}}
71+
72+
Par exemple, pour détecter des clients de conteneur suspects, utilisez l'expression suivante :
73+
74+
```text
75+
exec.file.path in ["/usr/bin/docker", "/usr/local/bin/docker",
76+
"/usr/bin/kubectl", "/usr/local/bin/kubectl"] && container.id != ""
77+
```
78+
79+
4. Cliquez sur **Create Agent Rule**. Vous revenez alors automatiquement à la page **Agent Configuration**.
80+
81+
Une fois que vous avez créé une règle d'Agent personnalisée, la modification est enregistrée avec les autres mises à jour de règle en attente. Pour appliquer la modification à votre environnement, [déployez la stratégie personnalisée mise à jour dans l'Agent](#deployer-la-strategie-dans-votre-environnement).
82+
83+
### Déployer la stratégie dans votre environnement
84+
85+
Vous pouvez utiliser la configuration à distance pour déployer automatiquement la stratégie personnalisée dans les hosts désignés (tous les hosts ou seulement un sous-ensemble de hosts), ou l'envoyer manuellement vers l'Agent sur chaque host.
86+
87+
<div class="alert alert-info">La fonctionnalité de configuration à distance des règles personnalisées est actuellement en bêta privée. Remplissez <a href="https://docs.google.com/forms/d/e/1FAIpQLSe5Emr7y_Jg3ShcC44HlYtalxKgHUocFAz8dq87xSkjfeALTg/viewform">ce formulaire</a> pour demander à y accéder.</div>
88+
89+
#### Configuration à distance
90+
91+
1. Sur la page **Agent Configuration**, cliquez sur **Deploy Agent Policy**.
92+
2. Sélectionnez **Remote Configuration**.
93+
3. Choisissez **Deploy to All Hosts** ou **Deploy to a Subset of Hosts**. Pour déployer la stratégie dans un sous-ensemble de hosts, spécifiez les hosts en sélectionnant un ou plusieurs tags de service.
94+
4. Cliquez sur **Deploy**.
95+
96+
#### Déploiement manuel
97+
98+
1. Sur la page **Agent Configuration**, cliquez sur **Deploy Agent Policy**.
99+
2. Sélectionnez **Manual**.
100+
3. Cliquez sur **Download Agent Policy**, puis sur **Done**.
101+
102+
Procédez ensuite comme indiqué ci-dessous pour envoyer le fichier de stratégie vers chaque host.
103+
104+
{{< tabs >}}
105+
{{% tab "Host" %}}
106+
107+
Placez le fichier `default.policy` dans le dossier `{$DD_AGENT}/runtime-security.d` du host cible. Le fichier doit au minimum accorder les accès `read` et `write` à l'utilisateur `dd-agent` sur le host. Il peut être nécessaire d'utiliser un utilitaire comme SCP ou FTP.
108+
109+
Pour appliquer les modifications, redémarrez l'[Agent Datadog][1].
110+
111+
[1]: /fr/agent/configuration/agent-commands/?tab=agentv6v7#restart-the-agent
112+
113+
{{% /tab %}}
114+
115+
{{% tab "Helm" %}}
116+
117+
1. Créez une ConfigMap contenant `default.policy`, par exemple, `kubectl create configmap jdefaultpol --from-file=default.policy`.
118+
2. Ajoutez la ConfigMap (`jdefaultpol`) au fichier `values.yaml` avec la commande `datadog.securityAgent.runtime.policies.configMap`:
119+
120+
```yaml
121+
securityAgent:
122+
compliance:
123+
# [...]
124+
runtime:
125+
# datadog.securityAgent.runtime.enabled
126+
# Set to true to enable Security Runtime Module
127+
enabled: true
128+
policies:
129+
# datadog.securityAgent.runtime.policies.configMap
130+
# Place custom policies here
131+
configMap: jdefaultpol
132+
syscallMonitor:
133+
# datadog.securityAgent.runtime.syscallMonitor.enabled
134+
# Set to true to enable Syscall monitoring.
135+
enabled: false
136+
```
137+
138+
3. Mettez à niveau le chart Helm avec la commande `helm upgrade <NOM_VERSION> -f values.yaml --set datadog.apiKey=<CLÉ_API> datadog/datadog`.
139+
140+
**Remarque :** si vous devez apporter d'autres modifications à `default.policy`, vous pouvez soit utiliser la commande `kubectl edit cm jdefaultpol`, soit remplacer la ConfigMap avec `kubectl create configmap jdefaultpol --from-file default.policy -o yaml --dry-run=client | kubectl replace -f -`.
141+
142+
4. Redémarrez l'[Agent Datadog][1].
143+
144+
[1]: /fr/agent/configuration/agent-commands/?tab=agentv6v7#restart-the-agent
145+
146+
{{% /tab %}}
147+
{{< /tabs >}}
148+
149+
### Configurer la règle de détection
150+
151+
Après avoir envoyé le nouveau fichier de stratégie vers l'Agent, accédez à la page [**Rules**][3].
152+
153+
1. Sur la page [**Detection Rules**][3], cliquez sur **New Rule**.
154+
2. Sélectionnez **Workload Security** sous **Rule types**. Choisissez une méthode de détection, par exemple **Threshold** ou **New Value**.
155+
3. Configurez une nouvelle règle CSM Threats. Une règle peut présenter plusieurs scénarios de règle combinés à l'aide d'une logique booléenne, comme `(||, &&)`. Vous pouvez également définir les paramètres Counter, group by et roll-up over.
156+
157+
{{< img src="security/cws/workload_security_rules/define_runtime_expression2.png" alt="Ajout d'une règle dans le champ de requêtes de recherche" >}}
158+
159+
4. Dans le champ **Only generate a signal if there is a match**, saisissez une requête pour définir les valeurs pour lesquelles un déclencheur sera généré. Vous pouvez également saisir des requêtes de suppression dans le champ **This rule will not generate a signal if there is a match** pour spécifier des valeurs pour lesquelles aucun déclencheur ne sera généré.
160+
5. Définissez la logique à appliquer pour que la règle déclenche un signal de sécurité. Par exemple, `a>0` signifie qu'un signal de sécurité est déclenché dès lors que la condition définie à l'étape 3 est remplie au moins une fois dans la fenêtre temporelle glissante. Sélectionnez une gravité à associer à la règle et choisissez toutes les parties à notifier.
161+
162+
{{< img src="security/cws/workload_security_rules/rule_cases2.png" alt="Définition d'un déclencheur, d'une gravité et de réglages de notification pour une règle" >}}
163+
164+
6. Définissez un déclencheur, une gravité et des réglages de notification pour la règle. Attribuez-lui un nom et ajoutez le message de notification au format Markdown. Utilisez des [variables de notification][5] pour fournir des détails spécifiques concernant le signal en référençant ses tags et ses attributs d'événement. Après le message, ajoutez les tags de votre choix pour préciser le contexte dans lequel les signaux ont été générés par votre règle personnalisée.
165+
166+
**Remarque **: Datadog recommande d'inclure un runbook de correction automatique dans le corps du message. Comme indiqué dans le modèle, utilisez des variables de substitution pour générer dynamiquement du contenu contextualisé lors de l'exécution.
167+
168+
## Désactiver les règles d'Agent par défaut
169+
170+
Pour désactiver une règle d'Agent par défaut, accédez à la page [**Agent Configuration**][6] et cliquez sur le bouton d'activation ou de désactivation de la règle. Lorsque vous désactivez une règle d'Agent par défaut, la modification est enregistrée avec les autres mises à jour de règle en attente. Pour appliquer la modification à votre environnement, [déployez la stratégie personnalisée mise à jour dans l'Agent](#deployer-la-strategie-dans-votre-environnement).
171+
172+
## Pour aller plus loin
173+
{{< partial name="whats-next/whats-next.html" >}}
174+
175+
[1]: /fr/security/default_rules/#cat-workload-security
176+
[2]: /fr/security/threats/agent_expressions
177+
[3]: https://app.datadoghq.com/security/configuration/rules?product=cws
178+
[4]: https://app.datadoghq.com/security/configuration/agent-rules
179+
[5]: /fr/security/notifications/variables/
180+
[6]: https://app.datadoghq.com/security/configuration/workload/agent-rules
181+
[7]: /fr/security/threats/setup?tab=kuberneteshelm#enable-remote-configuration
182+
[8]: /fr/security/threats/security_signals

0 commit comments

Comments
 (0)