Notes de mise à jour
1.0.0 (Requires minimum Cloud Exchange version 6.1.0)
Added
- Initial release.
- Types de journaux : alertes, événements, WebTx, journaux
- Format Type: CEF, JSON
Ce document explique comment configurer le plugin AWS CloudWatch v1.0.0 avec le module Log Shipper de la plateforme Netskope Cloud Exchange. Ce plugin prend en charge l’ingestion de :
- Alertes (DLP (Prévention des pertes de données), logiciels malveillants, politiques, identifiants compromis, sites malveillants, quarantaine, remédiation, évaluation de la sécurité, liste de surveillance, UBA, CTEP, périphériques, contenu, anomalie, suspension légale)
- Événements (page, application, audit, infrastructure, réseau, incident, point de terminaison, état du client)
- Événements BWAN (authentification, audit, client, passerelle, système)
- WebTx et journaux (débogage, informations, erreur, avertissement).
Ce plugin prend en charge l'ingestion aux formats CEF et JSON.
Conditions préalables
Pour compléter cette configuration, vous avez besoin de :
- Un locataire Netskope (ou plusieurs, par exemple des instances de production et de développement/test).
- Un locataire Netskope Cloud Exchange avec le plugin Tenant et le plugin Log Shipper déjà configuré.
- Un locataire Netskope Cloud Exchange avec le plugin BWAN déjà configuré.
- Les plugins de streaming de logs AWS et Azure Log Streaming déjà configurés, pour ingérer des alertes, des événements et des WebTx à partir du plugin Netskope Log Streaming.
- Autorisations des logs Amazon CloudWatch pour l'utilisateur IAM.
- DescribeLogGroups
- DescribeLogStreams
- CreateLogGroup
- CreateLogStream
- PutLogEvents
- Connectivité au service AWS CloudWatch.
- Pour la configuration de Secret Manager, reportez-vous à cette documentation et pour configurer Azure Key Vault Secrets Manager, reportez-vous à cette documentation.
Prise en charge du plugin AWS CloudWatch
Ce plugin prend en charge l'ingestion aux formats CEF et JSON.
| Type de données | Support |
|---|---|
| Événements | Oui (Page, Application, Audit, Infrastructure, Réseau, Incident, Point final, Statut du client) |
| Alertes | Oui (DLP (Prévention des pertes de données), Malware, Policy, Compromised Credential, Malsite, Quarantine, Remediation, Security Assessment, Watchlist, UBA, CTEP, périphérique, Content) |
| Cloud Exchange Logs | Oui (Info, Erreur, Avertissement, Débogage) |
| Événements BWAN | Oui (authentification, audit, client, passerelle, système) |
| WebTx | Oui (via Netskope LogStreaming) |
Détails de l'API
Liste des API utilisées
Ce plugin utilise des bibliothèques Python pour créer des groupes de journaux, des flux de journaux et des événements de journaux dans AWS CloudWatch Logs.
Library: The AWS SDK for Python (Boto3)
Utilisation : Le kit SDK AWS pour Python (Boto3) est utilisé pour créer, configurer et gérer les services AWS, tels qu’Amazon CloudWatch Logs. Le kit SDK fournit une interface de programmation (API) orientée objet ainsi qu’un accès de bas niveau aux services AWS. Ce plugin utilise uniquement le client logs de bas niveau, qui correspond un-à-un à l’API Amazon CloudWatch Logs.
Reportez-vous à la documentation officielle pour plus d’informations sur le client CloudWatch Logs de Boto3. https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/logs.html
Créer un client
Le client est créé avec les informations d’identification résolues à partir de la méthode d’authentification sélectionnée, la région dérivée du nom de la région AWS CloudWatch ou de la région personnalisée AWS CloudWatch, les paramètres de proxy et de vérification SSL configurés, et l’agent utilisateur Netskope APN. Lors de la validation de la configuration, le compteur de tentatives est défini sur 0 afin que l’erreur soit immédiatement signalée à l’utilisateur ; sur le chemin d’envoi, il est défini sur 3 avec le mode de nouvelle tentative standard.
cloudwatch_client = boto3.client(
"logs",
aws_access_key_id=self.aws_public_key,
aws_secret_access_key=self.aws_private_key,
aws_session_token=self.aws_session_token,
region_name=get_effective_region(self.configuration),
verify=self._get_verify(),
config=Config(
proxies=self.proxy,
user_agent=self.useragent,
connect_timeout=CONNECT_TIMEOUT,
read_timeout=READ_TIMEOUT,
retries={"max_attempts": MAX_RETRIES, "mode": "standard"},
),
)
Vérifier les identifiants AWS (DescribeLogGroups)
Un seul appel DescribeLogGroups effectué lors de la validation de la configuration pour confirmer que les informations d'identification sont valides et que le rôle peut lire les journaux CloudWatch. Aucun événement de journal n'est écrit.
cloudwatch_client.describe_log_groups(
logGroupNamePrefix=log_group_name, limit=1
)
Vérifier l’existence du groupe de logs (DescribeLogGroups)
Recherche paginée utilisée lors de la validation de la configuration pour déterminer si le nom de groupe de journaux configuré existe déjà, afin que le plugin ne le crée que lorsqu'il est manquant. Jusqu'à 20 pages de 50 groupes de journaux sont analysées.
response = cloudwatch_client.describe_log_groups(
logGroupNamePrefix=log_group_name,
limit=DESCRIBE_PAGE_LIMIT,
nextToken=next_token,
)
Vérifier l’existence du flux de journaux (DescribeLogStreams)
Recherche paginée utilisée lors de la validation de la configuration pour savoir si le nom du flux de journaux configuré existe déjà dans le groupe de journaux.
response = cloudwatch_client.describe_log_streams(
logGroupName=log_group_name,
logStreamNamePrefix=log_stream_name,
limit=DESCRIBE_PAGE_LIMIT,
nextToken=next_token,
)
Créer un groupe de journaux
Crée le groupe de journaux configuré dans le nom du groupe de journaux lorsqu'il n'existe pas encore.
cloudwatch_client.create_log_group(logGroupName=log_group_name)
Créer un flux de journaux
Crée le flux de journaux configuré dans Nom du flux de journaux dans le groupe de journaux lorsqu'il n'existe pas déjà.
cloudwatch_client.create_log_stream(
logGroupName=log_group_name,
logStreamName=log_stream_name,
)
Pousser les journaux vers le flux de journaux (PutLogEvents)
Télécharge un lot d’événements de journal vers le groupe de journaux et le flux de journaux configurés. Il s’agit de l’appel qui effectue l’ingestion réelle.
log_events = [
{"timestamp": timestamp_ms, "message": message}
for message in batch
]
cloudwatch_client.put_log_events(
logGroupName=log_group_name,
logStreamName=log_stream_name,
logEvents=log_events,
)
Les lots sont constitués dans les limites AWS ci-dessous, et les événements sont triés par horodatage avant l'appel, conformément aux exigences de l'API.
| Limit | Value |
|---|---|
| Nombre maximum d’événements de journal par requête | 10,000 |
| Taille maximale de la requête | 1 048 576 octets |
| Taille maximale d’un événement de journal unique | 1 048 576 octets |
| Overhead AWS adds per log event | 26 octets |
La réponse est inspectée pour rejectedLogEventsInfo afin que les événements rejetés par AWS comme étant trop anciens, trop New ou expirés soient comptabilisés et signalés plutôt que de faire l’objet d’une nouvelle tentative.
Library: Requests
Utilisation : La bibliothèque requests est un client HTTP pour Python. Le plugin l’utilise pour appeler l’API CreateSession d’AWS IAM Roles Anywhere, qui n’est pas exposée par le client Boto3 CloudWatch Logs. Cet appel n’est effectué que lorsque la méthode d’authentification est définie sur AWS IAM Roles Anywhere.
Reportez-vous à la documentation officielle pour plus d'informations sur la bibliothèque requests. https://requests.readthedocs.io/en/latest/
Générer des identifiants temporaires (CreateSession)
Le certificat X.509 et la clé privée configurés sont échangés contre des identifiants AWS de courte durée, qui sont ensuite utilisés pour créer le client Boto3 CloudWatch Logs. La demande est signée avec l'algorithme AWS4-X509-RSA-SHA256.
# endpoint = "https://rolesanywhere.{region}.amazonaws.com"
# ("amazonaws.com.cn" for the China partition)
# canonical_uri = "/sessions"
request_parameters = json.dumps(
{
"durationSeconds": 900,
"profileArn": profile_arn,
"roleArn": role_arn,
"sessionName": "Session",
"trustAnchorArn": trust_anchor_arn,
}
)
headers = {
"Content-Type": "application/json",
"X-Amz-Date": amz_date,
"X-Amz-X509": amz_x509,
"Authorization": authorization_header,
"User-Agent": self.user_agent,
}
response = requests.post(
endpoint + canonical_uri,
data=request_parameters,
headers=headers,
proxies=self.proxy,
timeout=ROLES_ANYWHERE_TIMEOUT,
verify=self.verify,
)
La réponse porte credentialsSet[0].credentials contenant accessKeyId, secretAccessKey, sessionToken et expiration. Les informations d'identification sont valides pendant 900 secondes et sont automatiquement actualisées par le plugin 3 minutes avant leur expiration. L'appel utilise un délai de connexion de 10 secondes et un délai de lecture de 60 secondes.
Reportez-vous à la documentation officielle pour plus d’informations sur AWS IAM Roles Anywhere. https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateSession.html
Library: Cryptography
Utilisation : la bibliothèque de cryptographie fournit des primitives cryptographiques et la gestion des certificats X.509 pour Python. Le plugin l'utilise uniquement pour la méthode d'authentification AWS IAM Roles Anywhere, afin de construire la signature de la requête CreateSession.
Reportez-vous à la documentation officielle pour plus d'informations sur la bibliothèque de cryptographie. https://cryptography.io/en/latest/
Charger la clé privée
La clé privée configurée est chargée sans phrase de passe en premier lieu, et avec la phrase de passe lorsque la clé est chiffrée.
private_key = serialization.load_pem_private_key(
private_key_file.encode("utf-8"), None
)
# Encrypted key
private_key = serialization.load_pem_private_key(
private_key_file.encode("utf-8"),
password=str.encode(pass_phrase),
)
Charger le certificat et construire l’en-tête X.509
Le corps du certificat configuré est chargé pour dériver l’encodage DER envoyé dans l’en-tête X-Amz-X509 et le numéro de série utilisé dans le champ d’identification de l’en-tête d’autorisation.
cert = x509.load_pem_x509_certificate(
public_certificate_file.encode()
)
amz_x509 = str(
base64.b64encode(
cert.public_bytes(encoding=serialization.Encoding.DER)
),
"utf-8",
)
serial_number_dec = cert.serial_number
Signer la demande
La chaîne canonique est signée avec le remplissage PKCS#1 v1.5 et SHA-256, et la signature hexadécimale est placée dans l'en-tête Authorization.
signature = private_key.sign(
data=string_to_sign.encode("utf-8"),
padding=padding.PKCS1v15(),
algorithm=hashes.SHA256(),
)
signature_hex = signature.hex()
Matrice de performance
Cette analyse des performances est réalisée sur un CE à grande pile avec ces spécifications de VM.
| Description | Spécifications |
|---|---|
| Détails de la pile | Taille : Grande RAM : 32 GB CPU : 16 cœurs |
| Alertes/événements intégrés au SIEM | ~200K EPM |
| WebTx (via Netskope LogStreaming) ingéré dans SIEM | ~165 000 EPM |
Agent utilisateur
APN/1.1 (ahq9d89xj9gspapczzdb59goq)
Workflow
- Créer un groupe de journaux AWS CloudWatch, un flux de journaux et une politique.
- Générer la clé privée, le corps du certificat, la phrase de passe, l'ARN du profil, l'ARN du rôle, l'ARN de l'ancre de confiance si vous utilisez AWS IAM Role Anywhere.
- Configurer le plugin AWS CloudWatch.
- Configurer une règle de gestion de l'expéditeur de logs pour AWS CloudWatch.
- Configurer la livraison des journaux Log Shipper pour AWS CloudWatch.
- Valider le plugin AWS CloudWatch.
Regardez une vidéo
Cliquer sur « play » pour regarder une vidéo.
Créer un groupe de journaux CloudWatch
- Connectez-vous à la console AWS.
- Dans Tous les services, sélectionnez CloudWatch, ou recherchez CloudWatch dans la barre de recherche.
- Vérifiez le sélecteur de région en haut à droite. Le groupe de journaux est créé dans cette région, et vous sélectionnerez la même région dans le paramètre Nom de région AWS CloudWatch du plugin.
- Dans le panneau de gauche, cliquez sur Logs > Log groups.
- Cliquez sur Create log group.
- Enter the Log group name, like netskope-ce-log-group.
- Select un paramètre de rétention, *Ne jamais expirer*, ou une période dont votre organisation a besoin.
- Select Standard pour la classe de journal.
- L’ARN de la clé KMS et les balises sont facultatifs.
- Cliquez sur Create.
Créer un flux de journaux CloudWatch
- Dans CloudWatch, allez dans Logs > Log groups.
- Recherchez le groupe de journaux que vous avez créé ci-dessus et cliquez sur son nom pour l’ouvrir.
- Ouvrez l’onglet Flux de journaux.
- Cliquez sur Create log stream.
- Enter the Log stream name, like netskope-ce-log-stream.
- Cliquez sur Create.
Créer une politique de logs CloudWatch
-
Recherchez IAM dans la zone de recherche et, dans le panneau de gauche, cliquez sur Policies.
-
Cliquez sur Create Policy.

-
Cliquez sur l'onglet JSON et saisissez la politique mentionnée ci-dessous. Cliquez sur Suivant : Tags, cliquez sur Suivant : Vérifier

{ "Version": "2012-10-17", "Statement": [ { "Sid": "NetskopeCECloudWatchLogs", "Effect": "Allow", "Action": [ "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] } -
Attachez cette stratégie à l’utilisateur :
-
Allez dans IAM > Users et sélectionnez l’utilisateur auquel vous souhaitez attacher une politique. Cliquez sur Add permissions puis sur Add permissions options.

-
Select l'option Attach policies directly sous les options Autorisations. Recherchez et sélectionnez la politique créée à l'étape précédente.

-
Cliquez sur Next, puis sur Add permissions. La politique sera jointe à l'utilisateur.

-
Méthodes d'authentification des plugins
Configuration de IAM Role Anywhere
Conditions préalables
Le service AWS Certificate Manager doit être activé pour authentifier le plugin à l'aide de la méthode d'authentification AWS IAM Roles Anywhere.
Assurez-vous de créer l'autorité de certification privée, l'ancre de confiance et le profil dans la même région que celle où se trouve votre AWS S3 Source Bucket.
Créer une politique
Cette politique contient les autorisations requises pour la création d'un certificat d'autorité de certification privée (y compris les autorisations pour la création d'une ancre de confiance et d'un profil) et pour l'utilisation des rôles IAM Anywhere.
-
Allez dans Générateur de politiques, sélectionnez Politique IAM comme type de politique et générez une politique.
- Select Type of Policy: Politique IAM
- Effect: Permettre
- AWS Service: Autorité de certification privée AWS
- Actions:
- Créer une autorité de certification
- DescribeCertificateAuthority
- Obtenir un certificat
- Obtenir un certificat d'autorité
- Obtenir l'autorité de certification (GetCertificateAuthorityCsr)
- ImportCertificateAuthorityCertificate
- Délivrer un certificat
- Liste des autorités de certification
- ARN: *
- Cliquez sur Add Statement.
- Select Type of Policy: Politique IAM
- Effect: Permettre
- AWS Service: gestion des identités et des accès (IAM) AWS
- Actions:
- Politique de rattachement des rôles
- Créer une clé d'accès
- Créer un rôle
- Supprimer un rôle
- PassRole
- ARN: *
- Cliquez sur Add Statement.
- Select Type of Policy: Politique IAM
- Effect: Permettre
- AWS Service: Gestionnaire de certificats AWS
- Actions:
- Décrire le certificat
- Certificat d'exportation
- Obtenir un certificat
- Liste des certificats
- ListTagsForCertificate
- Demande de certificat
- ARN: *
- Cliquez sur Add Statement.
- Select Type of Policy: Politique IAM
- Effect: Permettre
- AWS Service: Rôles AWS Identity and Access Management Anywhere
- Actions:
- Créer un profil
- CreateTrustAnchor
- Obtenir un profil
- GetTrustAnchor
- Liste des profils
- ListTrustAnchors
- ARN: *
- Cliquez sur Add Statement.
- Cliquez sur Generate Policy.
- Copiez la politique car elle sera utilisée dans l'étape suivante pour créer la politique nécessaire à la création des certificats de l'AC privée.
-
Accédez à la console AWS et sélectionnez IAM dans All Services. Cliquez sur Policies dans le panneau de gauche, puis cliquez sur Create Policy.

-
Copiez la stratégie dans l’onglet JSON. Cliquez sur Next: Tags, puis sur Next: Review.

-
Enter the Name (like netskope-ce-rolesAnywhere-policy), and click Save Changes.






Créer une autorité de certification privée
-
Connectez-vous à la console AWS.
-
Cherche Certificate Manager.

-
Cliquez sur AWS Private CA.
-
Cliquez sur Create a private CA.

-
Pour les options de mode, sélectionnez General-purpose.
-
Pour les options de type CA, sélectionnez Root.

-
Saisissez une organisation (O).

-
Pour les options de l’algorithme de clé, sélectionnez RSA 2048.


-
Add tags if any (optional).
-
Cochez la case dans la section Options d’autorisations CA.
-
Cochez la case dans la section Tarification.
-
Cliquez sur Create pour créer le certificat CA.


-
À partir de Actions, sélectionnez Install.

-
Cliquez sur Confirm and Install.


Créer une ancre de confiance
-
Recherchez le service IAM et allez sur Roles sous Gestion des accès. Faites défiler vers le bas jusqu’à Rôles Anywhere et sélectionnez Manage.

-
Cliquez sur Create a Trust anchor.

-
Enter a Trust anchor name, like netskope-ce-trust-anchor.

-
Select AWS Certificate Manager Private CA (créé aux étapes précédentes) comme source de l'autorité de certification (CA).
-
Ajoutez des étiquettes si nécessaire.
-
Cliquez sur Create a trust anchor.


-
Cliquez sur l’ancre de confiance créée et copiez le Trust Anchor ARN

Créer un rôle IAM
-
Accédez aux services IAM dans la console AWS.
-
Cliquez sur Role dans le sous-menu Gestion des accès.
-
Cliquez sur Create Role.

-
Dans le type d’entité de confiance, sélectionnez Custom Trust Policy.

-
Remplacez la politique de confiance personnalisée par la politique de confiance donnée ci-dessous. Cette politique contient les autorisations nécessaires pour utiliser le service Roles Anywhere :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "rolesanywhere.amazonaws.com" ] }, "Action": [ "sts:AssumeRole", "sts:TagSession", "sts:SetSourceIdentity" ] } ] }
-
Cliquez sur Next.
-
Dans les politiques d’autorisation, sélectionnez la politique créée précédemment.

-
Cliquez sur Next.
-
Saisissez un nom de rôle et une description pour le rôle, comme netskope-ce-roleAnywhere.
-
Cliquez sur Create role.

-
Prenez note de Role ARN car cela sera requis dans le paramètre de configuration du plugin Role ARN pour la méthode d'authentification AWS IAM Roles Anywhere.

Créer un profil
-
Select Roles présent sous Access management.
-
Faites défiler vers le bas jusqu'à Roles Anywhere et cliquez sur Manage.

-
Développez les étapes de la configuration.
-
Cliquez sur Step 2: Configure roles.
-
Cliquez sur Configure a profile.

-
Enter a Profile name, like netskope-ce-profile.
-
Select le rôle créé précédemment (netskope-ce-roleAnywhere)

-
Supprimez la politique d’assurance en ligne.
-
Cliquez sur Create profile.



-
Cliquez sur le profil créé et copiez le Profile ARN.

Demander un certificat privé
-
Allez sur AWS Certificate Manager > Request certificate.
-
Select Request a private certificate.

-
Cliquez sur Next.
-
Select l'autorité de certification créée précédemment.

-
Saisissez un nom de domaine dans le champ Nom de domaine complet, comme netskope-ce.com.
-
Select RSA 2048 pour l'algorithme de la clé.

-
Ajoutez des étiquettes si nécessaire.
-
Confirmez les autorisations de renouvellement du certificat.
-
Cliquez sur Request.

-
Allez sur List certificates dans le volet de navigation d'AWS Certificate Manager.
-
Select le certificat créé précédemment.

-
Cliquez sur Export.

-
Saisissez le passphrase. Prenez note de la phrase secrète car elle sera nécessaire pour la configuration du plugin AWS S3 à l’aide de la méthode d’authentification AWS IAM Roles Anywhere.
-
Cliquez sur Generate PEM Encoding.

-
Téléchargez tous les Certificates car ils ne seront plus visibles. Pour les certificats New, vous devrez les exporter à nouveau.

Pour plus d’informations, rendez-vous sur AWS IAM Role Anywhere
Déployé sur AWS Configuration
Créer un rôle
-
Accédez aux services IAM dans la console AWS.
-
Cliquez sur Create role.

-
Select le AWS Service.
-
Sous Cas d'utilisation, sélectionnez EC2.
-
Cliquer sur Next.

-
Select la politique d'autorisation créée dans Créer une politique.
-
Cliquez sur Next.

-
Entrez un Nom de rôle, comme netskope-ce-instance-role, et une Description.
-
Cliquez sur Create Role.


Affecter un rôle à une instance EC2
-
Ouvrez la console de votre instance EC2.
-
Cliquez sur Instances sous Instances


-
Allez sur Action > Security > Modify IAM Role.

-
Select le rôle que vous avez créé ci-dessus dans Créer un rôle (netskope-ce-instance-role).
-
Cliquer sur Add IAM role/Modify IAM Role. Veuillez noter que l'instance EC2 et le bucket doivent se trouver dans la même région.

Attribuer un rôle à l'instance Fargate
-
Ouvrez votre script CFN.
-
Get the ExistingECSTaskRole parameter value if present.

-
Allez sur IAM > Roles.
-
Recherchez la valeur du paramètre ExistingECSTaskRole ou recherchez NetskopeCloudExchangeTaskRole-<CFN name> et sélectionnez le rôle.

-
Attacher la politique créée précédemment à ce rôle :
Attribuer un rôle à l'instance K8s
- Ouvrez votre rôle créé pour ServiceAccount lors de la création de l'instance K8s.
- Attachez la politique créée dans Créer une politique
Configurer le plugin AWS CloudWatch
-
Go to Settings > Plugin Store. Search for and select the AWS CloudWatch v1.0.0 (CLS) plugin.

-
Saisissez un nom de configuration de plugin et assurez-vous que le fichier de mappage par défaut AWS CloudWatch est sélectionné si vous souhaitez utiliser le format CEF.
Pour ingérer des données au format JSON, sélectionnez « JSON » comme format dans Informations de base. -
Cliquez sur Next et entrez les paramètres de configuration :
- Authentication Method: Select la méthode à utiliser pour l'authentification du client AWS.
Déployé sur AWS utilise le rôle IAM attaché à l'environnement AWS où Cloud Exchange s'exécute.
AWS IAM Roles Anywhere utilise un certificat X.509 et une clé privée pour obtenir des informations d'identification AWS temporaires, et est destiné à Cloud Exchange s'exécutant en dehors d'AWS. - Private Key: Clé privée encodée en PEM qui correspond au corps du certificat. Elle signe la demande CreateSession d’AWS IAM Roles Anywhere. Requis pour l’authentification AWS IAM Roles Anywhere.
- Certificate Body: Certificat d'entité finale X.509 codé en PEM émis par l'AC configurée dans l'ancre de confiance. Requis pour l’authentification AWS IAM Roles Anywhere.
- Password Phrase: Phrase secrète de la clé privée, si la clé est chiffrée. Requis pour l’authentification AWS IAM Roles Anywhere.
- Profile ARN: ARN du profil IAM Roles Anywhere. Format :
arn:aws:rolesanywhere:{region}:{account-id}:profile/{profile-id}. Requis pour l'authentification AWS IAM Roles Anywhere. - Role ARN: ARN du rôle IAM à assumer. Format :
arn:aws:iam::{account-id}:role/{role-name}. Le rôle nécessite logs:PutLogEvents sur le flux de journaux cible, et logs:CreateLogGroup et logs:CreateLogStream si le plugin doit les créer. Obligatoire pour l'authentification AWS IAM Roles Anywhere. - Trust Anchor ARN: ARN de l’ancre de confiance IAM Roles Anywhere. Format : arn:aws:rolesanywhere:{region}:{account-id}:trust-anchor/{anchor-id}. Requis pour l’authentification AWS IAM Roles Anywhere.
- AWS CloudWatch Region Name: Région AWS qui contient le groupe de journaux CloudWatch cible. Lorsque AWS IAM Roles Anywhere est utilisé, cette région doit correspondre à la région de l'ARN du profil et à l'ARN de l'ancre de confiance. Select Custom Region pour entrer une région qui ne figure pas dans la liste.
- AWS CloudWatch Custom Region: Utilisé uniquement lorsque le nom de la région AWS CloudWatch est défini sur Région personnalisée; sinon, laissez-le vide. N’importe quel code de région AWS valide du groupe de journaux, pour une région qui ne figure pas dans la liste, par exemple us-west-1. AWS IAM Roles Anywhere prend uniquement en charge les partitions aws, aws-cn et aws-us-gov, pas les régions ISO ou eusc-.
- Log Group Name: Nom du groupe de logs CloudWatch dans lequel les données sont écrites. Le plugin crée le groupe de logs s'il n'existe pas. Il peut comporter de 1 à 512 caractères et peut contenir des lettres, des chiffres et les caractères . – _ / #.
- Log Stream Name: Nom du flux de journalisation à l'intérieur du groupe de journaux. Le plugin crée le flux de journalisation s'il n'existe pas. Il peut comporter de 1 à 512 caractères et ne doit pas contenir de : ou de *.



- Authentication Method: Select la méthode à utiliser pour l'authentification du client AWS.
-
Cliquez sur Save. Votre configuration de plugin sera disponible sur la page Log Shipper > Plugins.

Configurer une règle de gestion de l'expéditeur de logs pour AWS CloudWatch
-
Accédez à la page Règle de gestion.
-
Par défaut, une règle de gestion filtre toutes les alertes et tous les événements. Si vous souhaitez filtrer un type spécifique d'alerte ou d'événement, cliquez sur Create New Rule et configurez une règle de gestion New en ajoutant le nom de la règle et le(s) filtre(s).

-
Cliquez sur Save.

Configurer la livraison de journaux Log Shipper pour AWS CloudWatch
- dans Log Shipper, allez dans Log Delivery et cliquez sur Add Log Delivery Configuration.
- Select le plugin source (CLS Netskope ou tout autre plugin source), le plugin de destination (CLS AWS CloudWatch) et la règle métier, puis cliquez sur enregistrer.
- Pour WebTx, sélectionnez le plugin source (CLS AWS Netskope LogStreaming) et le plugin de destination (CLS AWS CloudWatch).
- Pour le partage de journaux, sélectionnez le plugin source (CLS Cloud Exchange Logs) et le plugin de destination (CLS AWS CloudWatch).
- Pour le partage d'événements BWAN, sélectionner le plugin Source (CLS Netskope BWAN) et le plugin Destination (CLS AWS CloudWatch).
- Une fois la livraison des journaux ajoutée, les données commenceront à être extraites du locataire Netskope ou de la plateforme source, puis transformées et ingérées dans la plateforme AWS CloudWatch.

Valider le plugin AWS CloudWatch
Valider le retrait
Pour valider la récupération des événements, alertes, journaux, événements BWAN et WebTx du locataire Netskope.
Dans Cloud Exchange, aller dans Settings > Logging. Rechercher les journaux extraits.





Valider le push
Pour valider le plugin workflow dans Cloud Exchange:
Accédez à la journalisation et recherchez les événements, les alertes, les WebTx et les journaux ingérés avec le filtre « message contient ingéré ». Les journaux ingérés seront filtrés.





Pour valider le push dans AWS CloudWatch :
Connectez-vous à la plateforme AWS.

Recherchez CloudWatch et cliquez dessus.

Accédez à Logs > Log Analytics et saisissez une requête comme celle-ci :
SOURCE "arn:aws:logs:us-east-1:***********:log-group:<log_group_name>" START=-5m END=0s | fields @timestamp, @message | sort @timestamp desc | limit 10000 | filter @logStream like "<log_stream_name>"
Voici des exemples d'alertes ingérées :

Voici des exemples d'événements ingérés :

Voici à quoi ressemblent les événements BWAN du plugin vers AWS CloudWatch :

Voici à quoi ressemble AWS CloudWatch pour les logs CE du plugin vers AWS CloudWatch :

Voici à quoi ressemblent les données WebTx du plugin vers AWS CloudWatch :

Voici à quoi ressemblent les données lorsqu'elles sont partagées au format JSON du plugin vers AWS CloudWatch (format non analysé) :





Voici un exemple de données ingérées au format JSON avec un mappage personnalisé n'ayant que les champs sélectionnés :

Dépannage du plugin AWS CloudWatch
Aucune information d'identification AWS trouvée dans l'environnement
Error message:
Aucun identifiant AWS n'a été trouvé dans l'environnement. Déployez le plugin dans un environnement AWS ou utilisez l'authentification AWS IAM Roles Anywhere
Possible causes:
- La méthode d’authentification Déployé sur AWS est sélectionnée, mais aucun profil d’instance ou rôle IAM n’est attaché à l’hôte CE.
- AWS IAM Roles Anywhere est mal configuré et la chaîne d'identification ambiante est utilisée involontairement.
What to do:
- Vérifiez que l'hôte CE dispose d'un profil d'instance IAM avec les autorisations CloudWatch requises attachées (logs:PutLogEvents, logs:CreateLogGroup, logs:CreateLogStream, logs:DescribeLogGroups, logs:DescribeLogStreams), ou basculez la méthode d'authentification vers AWS IAM Roles Anywhere.
- Si vous utilisez IAM Roles Anywhere, confirmez que la clé privée (Private Key), le corps du certificat (Certificate Body), l'ARN du profil (Profile ARN), l'ARN du rôle (Role ARN) et l'ARN de l'ancre de confiance (Trust Anchor ARN) sont correctement configurés.
Accès refusé pour AWS IAM Roles Anywhere
Error message:
Accès refusé. Vérifiez l'ARN du profil, l'ARN du rôle et l'ARN de la ancre de confiance fournis dans les paramètres de configuration ainsi que les politiques attachées au rôle
Possible causes:
- Les ARN fournis dans la configuration ne correspondent pas ou sont incorrects.
- La politique de confiance du rôle IAM n’autorise pas le principal de service Roles Anywhere.
- Le rôle IAM ne dispose pas des autorisations CloudWatch Logs requises.
What to do:
- Vérifiez que l'ARN du profil, l'ARN du rôle et l'ARN de l'ancre de confiance sont corrects et font référence à des ressources existantes dans votre compte AWS.
- Confirmez que la politique de confiance du rôle IAM accorde les autorisations requises au service AWS IAM Roles Anywhere.
- Assurez-vous que le rôle IAM dispose des autorisations CloudWatch Logs nécessaires : logs:PutLogEvents, logs:CreateLogGroup, logs:CreateLogStream, logs:DescribeLogGroups et logs:DescribeLogStreams.
Ressource introuvable pour AWS IAM Roles Anywhere
Error message:
Ressource introuvable. Vérifiez l'ARN du profil, l'ARN du rôle et l'ARN de l'ancre de confiance fournis dans les paramètres de configuration
Possible causes:
- Un ou plusieurs des ARN configurés font référence à un profil, un rôle ou une ancre de confiance inexistant.
- Le format ARN est incorrect.
- Les ARN appartiennent à une région différente de celle sélectionnée dans AWS CloudWatch Region Name.
What to do:
- Connectez-vous à la console AWS et vérifiez que le profil, le rôle et l'ancre de confiance référencés par les ARN configurés existent et sont actifs.
- Assurez-vous que le format ARN est correct : arn:aws:rolesanywhere:{region}:{account-id}:profile/{profile-id}.
- Confirmez que la région dans l’ARN du profil et l’ARN de la banque d’approbation correspond au nom de la région AWS CloudWatch configuré dans le plugin.
Clé privée ou corps de certificat non valide
Error messages:
- Clé privée fournie non valide. La clé privée doit être dans un format PEM valide
- Corps de certificat non valide fourni. Le corps du certificat doit être au format PEM valide
Possible causes:
- Le champ Clé privée ne contient pas de clé privée valide encodée en PEM.
- Le champ Corps du certificat ne contient pas de certificat X.509 valide encodé en PEM.
- La phrase de passe est incorrecte pour une clé privée chiffrée.
What to do:
- Vérifiez que la clé privée commence par —–BEGIN RSA PRIVATE KEY—– ou —–BEGIN PRIVATE KEY—– et qu'elle est complète.
- Vérifiez que le corps du certificat commence par —–BEGIN CERTIFICATE—– et qu’il est complet.
- Confirmez que la phrase de mot de passe correspond à la phrase secrète utilisée lors de la génération de la clé privée, ou laissez ce champ vide si la clé n'est pas chiffrée.
Groupe de journaux CloudWatch inaccessible
Error messages:
- Le groupe de journaux AWS CloudWatch « {log_group} » n'existe pas ou n'est pas accessible
- ResourceNotFoundException : le groupe de journaux spécifié n'existe pas
Possible causes:
- Le nom du groupe de journaux configuré dans le plugin n’existe pas dans la région AWS spécifiée.
- Les informations d'identification IAM manquent des autorisations logs:DescribeLogGroups ou logs:CreateLogGroup requises.
- Le groupe de journaux existe dans une région différente de celle configurée.
What to do:
- Connectez-vous à la console CloudWatch Logs et vérifiez que le groupe de journaux existe dans la région configurée.
- Assurez-vous que le rôle IAM ou le profil d'instance dispose des autorisations logs:DescribeLogGroups et logs:CreateLogGroup.
- Si le groupe de journaux se trouve dans une autre région, mettez à jour le champ Région AWS dans la configuration du plugin pour correspondre à la région réelle du groupe de journaux.
Inadéquation de la région du groupe de journaux CloudWatch
Error message:
Le groupe de journaux AWS CloudWatch « {log_group} » existe mais se trouve dans la région « {actual} », et non dans la région configurée « {configured} »
Possible causes:
- La région AWS configurée dans le plugin ne correspond pas à la région réelle où réside le groupe de journaux.
- Les groupes de journaux CloudWatch sont des ressources spécifiques à une région.
What to do:
- Connectez-vous à la console CloudWatch Logs et confirmez la région réelle du groupe de logs.
- Mettez à jour le champ Région AWS dans la configuration du plugin pour qu'il corresponde à la région réelle du groupe de journaux.
Accès refusé lors de l'écriture dans les journaux CloudWatch
Error message:
AccessDeniedException : L'utilisateur n'est pas autorisé à effectuer : logs:PutLogEvents sur la ressource : {log_group}
Possible causes:
- Il manque au rôle IAM ou au profil d'instance une ou plusieurs autorisations CloudWatch Logs requises.
- Une stratégie basée sur les ressources ou une stratégie de contrôle des services (SCP) bloque l’action.
- Le groupe de journaux utilise le chiffrement AWS KMS et le rôle IAM ne dispose pas des autorisations de clé KMS correspondantes.
What to do:
Vérifiez que le rôle IAM dispose des autorisations suivantes sur le groupe de journaux cible :
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams",
"logs:DescribeLogGroups"
],
"Resource": "*"
}
- Vérifier la présence de politiques SCP ou de limites d'autorisations dans votre organisation AWS qui pourraient limiter l'accès aux logs CloudWatch.
- Si le groupe de journaux est chiffré avec une clé AWS KMS gérée par le client, assurez-vous que le rôle IAM dispose également des autorisations kms:GenerateDataKey et kms:Decrypt sur cette clé.
Limitation de CloudWatch Logs
Error message:
ThrottlingException : débit dépassé pour les journaux :PutLogEvents
Possible causes:
- Le plugin envoie des événements de journalisation à un débit qui dépasse le quota de service CloudWatch Logs pour PutLogEvents.
- Plusieurs instances CE écrivent simultanément dans le même flux de journaux.
What to do:
- Vérifiez les quotas de service CloudWatch Logs pour votre compte et demandez une augmentation si nécessaire.
- Assurez-vous que plusieurs instances CE ne sont pas en train d’écrire dans le même flux de journal en même temps ; utilisez des noms de flux de journaux uniques par instance.
Impossible d'atteindre AWS CloudWatch
Si l'utilisateur rencontre le message « Impossible d'atteindre AWS CloudWatch pendant {action}. Vérifiez la connexion réseau, les paramètres du proxy et le nom de la région AWS CloudWatch » ou « Une erreur s'est produite lors de la connexion à AWS CloudWatch », cela peut être dû à l'une des raisons suivantes :
- L’hôte CE ne peut pas atteindre le point de terminaison CloudWatch Logs pour la région configurée.
- Le proxy configuré dans Cloud Exchange est incorrect ou bloque la requête.
- La région configurée n’existe pas ; le nom d’hôte du point de terminaison ne se résout donc pas.
What to do:
- Vérifiez que l’hôte CE peut atteindre logs.{region}.amazonaws.com sur le port 443.
- Examinez la configuration du proxy dans Cloud Exchange et confirmez que le point de terminaison CloudWatch Logs est autorisé à travers le pare-feu.
- Confirmez que le nom de la région AWS CloudWatch (ou la région personnalisée AWS CloudWatch) est la région où le groupe de journaux réside.
La poussée s'est arrêtée après un lot défaillant
Si l’utilisateur rencontre le message : Le lot {n} sur {total} a échoué, l’envoi a donc été interrompu. {n} journal(aux) ont déjà atteint AWS CloudWatch et ont été supprimés de la nouvelle tentative. {n} journal(aux) seront envoyés à nouveau par Cloud Exchange, cela peut être dû à l’une de ces raisons :
- Une erreur d'identification, d'autorisation ou de réseau s'est produite lors d'un push.
- AWS a limité les appels PutLogEvents pour le flux de journaux cible.
What to do:
- Vérifiez les identifiants AWS, les autorisations IAM sur le groupe de journaux et la connexion réseau, en utilisant l'erreur spécifique enregistrée juste avant ce message.
- Aucune action n'est nécessaire pour les journaux eux-mêmes. Cloud Exchange ne renvoie automatiquement que le reste non envoyé, donc aucun journal n'est perdu ou dupliqué.
- Si le message se reproduit avec une erreur de limitation, demandez une augmentation du quota PutLogEvents pour le compte ou répartissez l’ingestion sur des flux de journaux supplémentaires.
Comportement connu
-
Vous pouvez rencontrer des caractères d'échappement dans les données ingérées en raison de plusieurs facteurs, tels que des caractères accentués (en anglais), des caractères de langues autres que l'anglais, des espaces insécables, des caractères de nouvelle ligne et d'autres symboles de formatage spéciaux.
Exemple :
<14>Apr 07 09:32:56 alltypes CEF:0|Netskope|Mock Netskope Tenant|NULL|application|NULL|Unknown|act=Download appcategory=Cloud Storage applicationType=nspolicy browser=unknown \\u4ed5\\u4e8b cci=89 ccl=high device=Other dst=ef82::1a12:1234:1b12 os=unknown requestClientApplication=Box sourceServiceName=Box src=ef82::1a12:1234:1b12 suser=support@netskope.com timestamp=1743736484
Ici, nous avions 2 caractères japonais ingérés, qui ressemblaient à « \\u4ed5\\u4e8b » dans le journal ci-dessus.
- Le contenu ingéré peut présenter des champs/données manquants si vous avez défini le champ "Pull DLP (Prévention des pertes de données) Incident Forensics" sur "Oui" ou si le contenu de l'un des champs est très volumineux.
- Nous avons observé que certains champs sont très volumineux et que leur longueur dépasse la longueur maximale prise en charge par Netskope Cloud Exchange. En raison de cela, vous pouvez rencontrer l'avertissement et vous pouvez observer que l'événement ingéré est incomplet car le reste des valeurs sera ignoré.



