Aller au contenu principal
Dernière mise à jour le

Logs système Okta

info

Aperçu

Lakewatch est en Aperçu privé. Pour demander l'accès, contactez l'équipe de votre compte Databricks.

Lakewatch fournit un connecteur API pour ingérer des logs système d'Okta. Cet article couvre les prérequis, les instructions de configuration, les schémas de connecteur et les observables d'analyseur Lakewatch.

Prérequis​

Le connecteur nécessite :

  1. Lakeflow Spark Declarative Pipelines serverless activé dans votre workspace.
  2. Unity Catalog, avec les privilèges de créer ou d’utiliser une connexion Unity Catalog. Voir Autorisations de connexion.
  3. Un compte Super administrator, Org administrator ou Read-only administrator Okta actif. Databricks recommande d’utiliser un compte d’administrateur en lecture seule pour accéder aux logs système avec un moindre privilège.
  4. Accès à la console d'administration Okta.
remarque

Un jeton d’API possède les mêmes autorisations que l’administrateur qui le crée. Si les autorisations de cet administrateur changent ou si le compte est désactivé, le jeton est affecté. Pour plus de détails, voir Gérer les jetons d’API Okta.

Limitations connues​

  • Le SCD de type 2 n’est pas pris en charge, car les logs système Okta sont en mode « ajout uniquement ».
  • Le connecteur prend en charge l’authentification uniquement via jeton d’API.
  • La période rétrospective historique ne peut pas dépasser les 90 jours pendant lesquels Okta conserve les logs système. Voir Choisir la période d'ingestion.

Configurer Okta pour l'ingestion​

  1. Connectez-vous à la console d’administration Okta avec le compte administrateur qui possède le jeton.
  2. Accédez à Sécurité > API .
  3. Cliquez sur le Jetons tab.
  4. Cliquez sur Créer un jeton .
  5. Saisissez un nom pour le jeton.
  6. Pour Les appels d’API effectués avec ce jeton doivent provenir de , sélectionnez N’importe quelle IP .
  7. Cliquez sur Créer un jeton .
  8. Copiez le jeton d’API SSWS affiché. Okta n’affiche plus le jeton.
  9. Notez le domaine de votre organisation Okta, tel que company-name.okta.com.
  10. Dans le tab Tokens , vérifiez que le Role du jeton est Super Admin , Organization Admin ou Read-only Admin .

Pour plus d’informations, consultez Gérer les jetons API Okta.

astuce

Lorsque vous créez une connexion via l'interface utilisateur de Lakewatch, vous avez besoin du domaine et du jeton d’API SSWS collectés ci-dessus.

Étapes suivantes​

Une fois la configuration ci-dessus terminée, créez une source de données avec le connecteur Okta dans l'interface utilisateur de Lakewatch. Voir Connecteurs d'API pour les instructions.

Schémas du connecteur et de Lakewatch​

Le connecteur ingère la table source suivante à partir du schéma source default :

Table source

Données Okta

Analyseur Lakewatch intégré

system_logs

Événements de sécurité des logs système Okta

okta_system_log

Table source

Données Okta

Analyseur Lakewatch intégré

system_logs

Événements de sécurité des logs système Okta

okta_system_log

Le connecteur écrit la table source dans la destination brute de la source de données. L'analyseur intégré écrit une table analysée séparée nommée d'après l'analyseur, sauf si vous définissez une destination analysée lors de la configuration de la source de données.

Colonnes gérées par Lakewatch​

Le connecteur ajoute les colonnes suivantes à chaque ligne source brute :

  • lw_id: une chaîne de caractères non nulle que Lakewatch utilise comme clé primaire. Le connecteur dérive un ID stable et triable par temps à partir des champs Okta published et uuid. L’ID prend en charge la déduplication au fil des synchronisations incrémentielles.
  • time: un timestamp non nul analysé à partir de published en tant que timestamp RFC 3339. Le connecteur utilise la valeur published source pour le classement incrémental.

La table analysée transfère lw_id. L’analyseur affecte également la colonne time analysée et ajoute :

  • lw_meta: Métadonnées de traitement Lakewatch standard.
  • lw_observables: Valeurs extraites des champs marqués comme observables de sécurité dans l’analyseur.

Pour plus d'informations, voir la Référence de l'analyseur.

Schéma brut de la table de connecteur​

Le schéma suivant combine les champs standard de Lakeflow Connect avec les colonnes lw_id et time propres à Lakewatch. Pour plus d’informations sur les définitions de champs imbriqués, consultez la référence de l’API Okta System Log.

Schéma

Colonne

Type de données

lw_id

STRING

time

TIMESTAMP

uuid

STRING

published

TIMESTAMP

eventType

STRING

version

STRING

severity

STRING

legacyEventType

STRING

displayMessage

STRING

actor

STRUCT<id: STRING, displayName: STRING, type: STRING, alternateId: STRING, detailEntry: MAP<STRING, STRING>>

authenticationContext

STRUCT<authenticationProvider: STRING, authenticationStep: INT, credentialProvider: STRING, credentialType: STRING, interface: STRING, externalSessionId: STRING, issuer: STRUCT<id: STRING, type: STRING>>

client

STRUCT<id: STRING, ipAddress: STRING, userAgent: STRUCT<rawUserAgent: STRING, os: STRING, browser: STRING>, zone: STRING, device: STRING, geographicalContext: STRUCT<city: STRING, state: STRING, country: STRING, postalCode: STRING, geolocation: STRUCT<lat: DOUBLE, lon: DOUBLE>>>

debugContext

STRUCT<debugData: MAP<STRING, STRING>>

outcome

STRUCT<result: STRING, reason: STRING>

device

STRUCT<id: STRING, name: STRING, os_platform: STRING, os_version: STRING, managed: BOOLEAN, registered: BOOLEAN, device_integrator: STRING, disk_encryption_type: STRING, screen_lock_type: STRING, jailbreak: BOOLEAN, secure_hardware_present: BOOLEAN>

transaction

STRUCT<type: STRING, id: STRING, detail: MAP<STRING, STRING>>

request

STRUCT<ipChain: ARRAY<STRUCT<ip: STRING, geographicalContext: STRUCT<city: STRING, state: STRING, country: STRING, postalCode: STRING, geolocation: STRUCT<lat: DOUBLE, lon: DOUBLE>>, version: STRING, source: STRING, ipDetails: STRUCT<asNumber: BIGINT, asOrg: STRING, isp: STRING, domain: STRING, ipServiceCategories: ARRAY<STRUCT<isAnonymous: BOOLEAN, operator: STRING, type: STRING>>>>>>

target

ARRAY<STRUCT<id: STRING, type: STRING, alternateId: STRING, displayName: STRING, detailEntry: MAP<STRING, STRING>, changeDetails: STRUCT<from: STRUCT<id: STRING, type: STRING, alternateId: STRING, displayName: STRING, detailEntry: MAP<STRING, STRING>>, to: STRUCT<id: STRING, type: STRING, alternateId: STRING, displayName: STRING, detailEntry: MAP<STRING, STRING>>>>>

securityContext

STRUCT<asNumber: BIGINT, asOrg: STRING, isp: STRING, domain: STRING, isProxy: BOOLEAN, ipDetails: STRUCT<asNumber: BIGINT, asOrg: STRING, isp: STRING, domain: STRING, ipServiceCategories: ARRAY<STRUCT<isAnonymous: BOOLEAN, operator: STRING, type: STRING>>>, risk: STRUCT<detectionName: STRING, issuer: STRING, level: STRING, previousLevel: STRING, reasons: ARRAY<STRING>>, UserBehaviours: ARRAY<STRUCT<id: STRING, name: STRING, result: STRING>>>

Colonne

Type de données

lw_id

STRING

time

TIMESTAMP

uuid

STRING

published

TIMESTAMP

eventType

STRING

version

STRING

severity

STRING

legacyEventType

STRING

displayMessage

STRING

actor

STRUCT<id: STRING, displayName: STRING, type: STRING, alternateId: STRING, detailEntry: MAP<STRING, STRING>>

authenticationContext

STRUCT<authenticationProvider: STRING, authenticationStep: INT, credentialProvider: STRING, credentialType: STRING, interface: STRING, externalSessionId: STRING, issuer: STRUCT<id: STRING, type: STRING>>

client

STRUCT<id: STRING, ipAddress: STRING, userAgent: STRUCT<rawUserAgent: STRING, os: STRING, browser: STRING>, zone: STRING, device: STRING, geographicalContext: STRUCT<city: STRING, state: STRING, country: STRING, postalCode: STRING, geolocation: STRUCT<lat: DOUBLE, lon: DOUBLE>>>

debugContext

STRUCT<debugData: MAP<STRING, STRING>>

outcome

STRUCT<result: STRING, reason: STRING>

device

STRUCT<id: STRING, name: STRING, os_platform: STRING, os_version: STRING, managed: BOOLEAN, registered: BOOLEAN, device_integrator: STRING, disk_encryption_type: STRING, screen_lock_type: STRING, jailbreak: BOOLEAN, secure_hardware_present: BOOLEAN>

transaction

STRUCT<type: STRING, id: STRING, detail: MAP<STRING, STRING>>

request

STRUCT<ipChain: ARRAY<STRUCT<ip: STRING, geographicalContext: STRUCT<city: STRING, state: STRING, country: STRING, postalCode: STRING, geolocation: STRUCT<lat: DOUBLE, lon: DOUBLE>>, version: STRING, source: STRING, ipDetails: STRUCT<asNumber: BIGINT, asOrg: STRING, isp: STRING, domain: STRING, ipServiceCategories: ARRAY<STRUCT<isAnonymous: BOOLEAN, operator: STRING, type: STRING>>>>>>

target

ARRAY<STRUCT<id: STRING, type: STRING, alternateId: STRING, displayName: STRING, detailEntry: MAP<STRING, STRING>, changeDetails: STRUCT<from: STRUCT<id: STRING, type: STRING, alternateId: STRING, displayName: STRING, detailEntry: MAP<STRING, STRING>>, to: STRUCT<id: STRING, type: STRING, alternateId: STRING, displayName: STRING, detailEntry: MAP<STRING, STRING>>>>>

securityContext

STRUCT<asNumber: BIGINT, asOrg: STRING, isp: STRING, domain: STRING, isProxy: BOOLEAN, ipDetails: STRUCT<asNumber: BIGINT, asOrg: STRING, isp: STRING, domain: STRING, ipServiceCategories: ARRAY<STRUCT<isAnonymous: BOOLEAN, operator: STRING, type: STRING>>>, risk: STRUCT<detectionName: STRING, issuer: STRING, level: STRING, previousLevel: STRING, reasons: ARRAY<STRING>>, UserBehaviours: ARRAY<STRUCT<id: STRING, name: STRING, result: STRING>>>

Observables de l’analyseur​

Le parser okta_system_log écrit les objets imbriqués sous la forme VARIANT et extrait les champs suivants dans lw_observables.

Observables

Champ

Observable

actor.id

actor_id

actor.alternateId

email

actor.alternateId

actor_id

actor.alternateId

username

client.ipAddress

ip

request.ipChain[].ip

ip

request.ipChain[].ipDetails.domain

domain

target[].id

actor_id

target[].alternateId

email

target[].alternateId

actor_id

target[].alternateId

username

securityContext.domain

domain

securityContext.ipDetails.domain

domain

Champ

Observable

actor.id

actor_id

actor.alternateId

email

actor.alternateId

actor_id

actor.alternateId

username

client.ipAddress

ip

request.ipChain[].ip

ip

request.ipChain[].ipDetails.domain

domain

target[].id

actor_id

target[].alternateId

email

target[].alternateId

actor_id

target[].alternateId

username

securityContext.domain

domain

securityContext.ipDetails.domain

domain

Dépannage​

Je reçois des erreurs de limitation de débit lors de l’ingestion de données.​

  1. Dans le panneau d’administration Okta, accédez à Sécurité >> API .
  2. Dans le tab Tokens, recherchez le jeton d’API que vous avez utilisé pour vous identifier auprès de Databricks.
  3. Cliquez sur le nom du jeton et dans la section Limites de débit du jeton , puis cliquez sur Modifier et augmentez le curseur à plus de 50 % de chaque limite de débit de l’API.
Sur cette page