Security Data Lake-ийн оролтууд (Inputs) — 10-р хэсэг: Okta Log Events Input, OpenTelemetry (gRPC) Input

← Үндсэн хуудас

Okta Log Events Input

Okta System Log нь таны байгууллагын үйл явдлыг бүртгэж, платформ дээрх үйлдлийн аудитын мөрийг хөтөлдөг. Энэ оролт (input) нь Okta Log Event объектуудыг татаж аваад байгууллагын үйл ажиллагааг цаашид шинжлэхээр Security Data Lake руу оруулна.

Okta Log Events input-ыг тохируулахдаа дараах алхмыг дагана.

1. Урьдчилсан нөхцөл хангагдсан эсэхийг шалгана

Дараах нөхцөлүүд хангагдсан байх ёстой:

• Администраторын эрхтэй, идэвхтэй Okta байгууллагын данс.

• Таны Okta tenant дээр API хандалт идэвхжсэн байх.

• Okta Admin Console-оос үүсгэсэн API token. Token нь System Log үйл явдлыг унших хангалттай эрхтэй байх ёстой.

• Okta System Log API-ийн endpoint URL. Ихэвчлэн дараах хэлбэртэй байна:

```
https://<your_okta_domain>/api/v1/logs
```

• Security Data Lake сервероос Okta API endpoint рүү сүлжээний хандалттай байх (порт 443, HTTPS).

2. Security Data Lake дээр оролтыг тохируулна

Оролт үүсгэх, тохируулах талаар Шинэ оролт (Input) тохируулах хэсгийн (Creating a new Pull input хэсэг) зааврыг үзнэ үү. Okta Log Events input нь System (Систем) > Inputs болон Enterprise > Forwarders > Input profiles хоёр газар хоёуланд нь байдгийг анхаараарай.

Оролтыг дараах тохиргоогоор тохируулна:

• Domain Name — Өөрийн Okta домэйн (Okta URL гэж бас нэрлэдэг)-ыг оруулна. Домэйныг Okta Developer Console-оос хуулж авна. Дэлгэрэнгүйг Find your domain хуудаснаас үзнэ үү.
• API Key — Security Data Lake-ийн Okta руу илгээх хүсэлтийг баталгаажуулах API token-ыг оруулна. API token-ыг Okta Developer Console-оос үүсгэнэ. Дэлгэрэнгүйг Create an Okta API token хуудаснаас үзнэ үү.
• Pull Log Events Since — Okta-ийн лог үйл явдлыг хамгийн эрт ямар цагаас эхлэн цуглуулахыг заана. Ингэснээр оролт эхлэх үед Security Data Lake өмнөх түүхэн өгөгдлийг хэр хэмжээгээр татахыг тодорхойлно. Заагаагүй бол Security Data Lake нэг polling interval-ийн хэмжээний түүхэн өгөгдлийг татна. Цагийн тэмдэг ISO 8601 форматтай байх ёстой.
• Polling Interval — Security Data Lake Okta-аас шинэ лог өгөгдлийг хэр давтамжтай шалгахыг тодорхойлно. Утга нь 5 секундээс бага байж болохгүй.
• Keyword Filter (заавал биш) — Лог үйл явдлын үр дүнг заасан түлхүүр үгээр шүүнэ. Зайгаар тусгаарласан 10 хүртэлх түлхүүр үг ашиглаж болох ба тус бүр нь хамгийн ихдээ 40 тэмдэгттэй байна.

OpenTelemetry (gRPC) Input

OpenTelemetry Google Remote Procedure Call (gRPC) input нь OpenTelemetry Protocol (OTLP)-ийг gRPC-ээр ашиглан OpenTelemetry-ээр хэмжилт хийсэн (instrumented) аппликейшн, үйлчилгээнүүдийн лог өгөгдлийг Bitdefender Forwarder-ээр дамжуулан Security Data Lake руу оруулах боломж олгоно.

Энэ оролтыг ашигласнаар бүтэцлэгдсэн OpenTelemetry логийг хүлээн авч, холбогдох талбаруудыг Security Data Lake-ийн дотоод схемд тохируулан, telemetry өгөгдөл дээрээ хайлт, шинжилгээ, анхааруулга (alerting) хийх боломжтой болно.

Урьдчилсан нөхцөл

Үргэлжлүүлэхийн өмнө дараах нөхцөл хангагдсан эсэхийг шалгана:

• OpenTelemetry Collector-ийг суулгана.

• OpenTelemetry лог Security Data Lake руу илгээхийн тулд Bitdefender Forwarder-ийг логийн backend болгон тохируулсан байх ёстой. Доорх тохиргооны хэсгүүд нь OpenTelemetry Collector-ийг Bitdefender Forwarder-ээр дамжуулан Security Data Lake руу лог илгээхээр тохируулах жишээ бөгөөд collector-ийн бүрэн тохиргоог харуулахгүй.

- Аюулгүй бус, баталгаажуулалтгүй лог экспортлох.

> Анхааруулга: Энэ тохиргоо аюулгүй бус тул production орчинд ашиглахыг зөвлөдөггүй. Зөвхөн туршилтад ашиглана!

```
exporters:
otlp/bitdefender:
endpoint: "<forwarder-ip>:4317"
tls:
insecure: true

service:
pipelines:
logs:
exporters: [debug, otlp/bitdefender]
```

- TLS, Bearer Token баталгаажуулалт

```
extensions:
bearertokenauth/withscheme:
scheme: "Bearer"
token: "kst40ngmpq22oqej9ugughgh48i81n0vbm0tbuqnqk0oop5jl0h"

exporters:
otlp/bitdefender:
endpoint: "<forwarder-ip>:4317"
auth:
authenticator: bearertokenauth/withscheme
tls:
ca_file: /tls/rootCA.pem

service:
extensions: [bearertokenauth/withscheme]
pipelines:
logs:
exporters: [debug, otlp/bitdefender]
```

- TLS, баталгаажуулалтгүй

```
exporters:
otlp/bitdefender:
endpoint: "<forwarder-ip>:4317"
tls:
ca_file: /tls/rootCA.pem

service:
pipelines:
logs:
exporters: [debug, otlp/bitdefender]
```

- Mutual TLS

```
exporters:
otlp/bitdefender:
endpoint: "<forwarder-ip>:4317"
tls:
ca_file: /tls/rootCA.pem
cert_file: /tls/client.pem
key_file: /tls/client-key.pem

service:
pipelines:
logs:
exporters: [debug, otlp/bitdefender]
```

Transport Layer Security (TLS)

Аюулгүй холболтыг хангахын тулд OpenTelemetry (gRPC) input нь баталгаажуулалт, шифрлэлтийн хэд хэдэн механизм санал болгодог бөгөөд тэдгээрийг тусад нь эсвэл нэмэлт хамгаалалтын үүднээс хослуулан ашиглаж болно. Аюулгүй байдлын тохиргоог уян хатан сонгох боломжтой:

• Зөвхөн TLS ашиглах: өгөгдөл шифрлэгдэх ч клиентийн баталгаажуулалт шаардахгүй.
• mTLS идэвхжүүлэх: зөвхөн хүчинтэй сертификаттай, итгэмжлэгдсэн клиентүүд холбогдоно.
• mTLS-ийн орлуулалт болгон Bearer Token баталгаажуулалт ашиглах: клиентүүд token-оор нэвтэрнэ.

Security Data Lake дээр оролтыг тохируулах

Оролт үүсгэх, тохируулах талаар Шинэ оролт (Input) тохируулах хэсгийн (Creating a new Listener input хэсэг) зааврыг үзнэ үү.

Оролтыг дараах тохиргоогоор тохируулна:

• Title — Оролтыг амархан таних нэр өгнө.
• Bind address — Энэ оролт сонсох IP хаягийг оруулна. Эх систем/өгөгдөл лог энэ IP хаяг/оролт руу илгээнэ.
• Port — Анхдагчаар оролт 0.0.0.0 дээр сонсох тул бүх сүлжээний интерфэйсээс хандах боломжтой бөгөөд OpenTelemetry-ийн gRPC-д суурилсан лог оруулалтын анхдагч порт болох 4317-ийг ашиглана.
• Maximum size of gRPC inbound messages — Мессежийн дээд хэмжээ. Анхдагч утга 4194304 байт (ойролцоогоор 4 MB) нь ихэвчлэн хангалттай боловч мессежийн уртаас хамааран өөрчилж болно.
• Allow Throttling (нүд) — Идэвхжүүлсэн бол Security Data Lake-ийн дотоод боловсруулалтын дараалал хязгаартаа хүрэхэд оролт шинэ мессеж унших үйлдлээ түр зогсооно. Throttling нь санах ойн хэт их ашиглалтаас сэргийлж, ялангуяа өндөр урсгалтай орчинд системийн тогтвортой байдлыг хангана. Лог өгөгдөл алдагдахгүй байхын тулд тохирох retry (дахин оролдох) үйлдлийг хэрэгжүүлнэ. OpenTelemetry SDK болон collector нь түр зуурын алдааны үед дахин оролдох механизмыг ерөнхийдөө дэмждэг боловч тэдгээрийн тохиргоо хүлээгдэж буй backoff болон retry бодлоготой тохирч байгаа эсэхийг шалгах хэрэгтэй.
• Required bearer token (заавал биш) — TLS-д нэмэлтээр эсвэл орлуулах баталгаажуулалтын арга болгон оролт Bearer Token баталгаажуулалтыг дэмждэг. Шаардлагатай Bearer Token тодорхойлсон үед бүх клиент хүсэлтийнхээ authorization header-т энэ token-ыг оруулах ёстой. Энэ арга нь клиент талд сертификат шаардахгүйгээр хандалтыг хянах боломж олгоно.
• Allow Insecure Connections (нүд) — Серверт аюулгүй бус холболт хийхийг зөвшөөрөхийн тулд TLS шифрлэлтийг идэвхгүй болгоно (зөвлөдөггүй).
• Override source (заавал биш) — Анхдагчаар source нь хүлээн авсан пакетаас гаргаж авсан hostname байдаг. Анхдагч утгыг өөрийн тохиргооны мөрөөр сольж болно. Энэ сонголтоор source-ыг өөрийн хэрэгцээнд тохируулан оновчилж болно.

OpenTelemetry логийн талбаруудыг Security Data Lake-ийн талбарт харгалзуулах

Лог хүлээн авсны дараа Security Data Lake нь үр дүнтэй индексжүүлэх, хайх зорилгоор OpenTelemetry логийн гол талбаруудыг дотоод схемдээ харгалзуулна. Security Data Lake нь мессеж доторх үүрлэсэн (nested) талбарыг дэмждэггүй тул OpenTelemetry Protobuf Specification-д заасан ирж буй лог дохионы бүтцийг Security Data Lake-ийн лог мессеж рүү яг хэвээр нь харгалзуулах боломжгүй. OpenTelemetry логийг Security Data Lake мессеж болгон хөрвүүлэхэд тодорхой дүрэм үйлчилнэ.

Дараах хэсгүүдэд OpenTelemetry лог мессеж Security Data Lake мессеж болж хэрхэн хөрвөхийг тайлбарлав.

Security Data Lake мессежийн үндсэн талбаруудын харгалзуулалт

Эдгээр талбар нь ирж буй OpenTelemetry лог бичлэгээс Security Data Lake мессежийн үндсэн талбарууд хэрхэн үүсэхийг харуулна.

• source: Оролт руу холболт эхлүүлсэн алсын талын хаяг.
• timestamp: OpenTelemetry логт time_unix_nano байвал түүнийг, үгүй бол observed_time_unix_nano-г, тэр ч байхгүй бол бичлэгийг оролт хүлээн авсан цагийг ашиглана.
• message: OpenTelemetry лог бичлэгийн body талбарын агуулга.

Нэгдүгээр түвшний талбарын харгалзуулалт

• `trace_id` — otel_trace_id
• `span_id` — otel_span_id
• `flags` — otel_trace_flags
• `severity_text` — otel_severity_text
• `severity_number` — otel_severity_number
• `time_unix_nano` — otel_time_unix_nano
• `observed_time_unix_nano` — otel_observed_time_unix_nano

(Зүүн талд нь OpenTelemetry талбар, баруун талд нь харгалзах Security Data Lake талбар.)

Resource болон Attributes харгалзуулалт

• Resource Attributes: otel_resource_attributes_ угтвартай болж Security Data Lake талбар болгон хөрвөнө.

• Resource Schema URL: otel_resource_schema_url талбарт харгалзана.

• Log Attributes: otel_attributes_ угтвартай болно.

• Log Schema URL: otel_schema_url талбарт харгалзана.

• Instrumentation Scope:

- otel_scope_name
- otel_scope_version
- otel_scope_attributes_*

Утгыг боловсруулах

• Энгийн төрлүүд (string, Boolean, integer, double): Шууд хөрвүүлнэ.

• Bytes: Base64-ээр кодлоно.

• Жагсаалт (Lists):

- Нэг төрлийн энгийн утгууд: Жагсаалт болгон хөрвүүлнэ.

- Холимог энгийн утгууд: Мөрийн (string) жагсаалт болгон хөрвүүлнэ.

- Үүрлэсэн массив/map: JSON болгон цуваална.

• Maps: _ тусгаарлагчаар тусдаа талбарууд болгон задална.

Анхаарах зүйл ба хязгаарлалт

Энэ оролт нь Security Data Lake-д OpenTelemetry-г дэмжих боломж олгодог боловч анхаарах хэд хэдэн чухал зүйл бий. Нэгдүгээрт, зөвхөн лог өгөгдлийг дэмжинэ. OTLP/gRPC-ээр дамжуулсан metrics болон traces-ийг энэ оролт хүлээн авахгүй. Хоёрдугаарт, OTLP over HTTP-ийг дэмждэггүй бөгөөд оролт зөвхөн gRPC transport-оор өгөгдөл хүлээн авна. Хэрэв Bitdefender Forwarder-ийг load balancer-ийн ард ажиллуулж байгаа бол шаардлагатай портууд нээлттэй байх, мөн TLS/mutual TLS тохиргоо зөв дамжиж аюулгүй, тасралтгүй холболтыг хадгалж байгаа эсэхийг заавал шалгах хэрэгтэй.