SIEM/Log Management Cơ chế phân quyền OpenSearch và tối ưu hóa tìm kiếm

I. Quyền hạn người dùng trong OpenSearch​

1. Định nghĩa​

Access Control là một tính năng trong bảo mật cho phép việc chọn lọc các quyền hạn cho người dùng, cho phép họ thực thi một số thao tác nhất định. [1]
Quyền hạn được cấu hình trong các vai rồi người dùng sẽ được gán một vai, những thao tác này sẽ bao gồm như: đọc, ghi, chỉnh sửa…
Do tính năng thuộc loại kiểm soát theo chi tiết (Fine-grained access control), điều này cho phép kiểm soát trên mức độ từ cluster, index, document đến field.

2. Các loại quyền hạn​

Quyền hạn index hệ thống: Quyền cho phép người dùng thao tác thay đổi bất kì index hệ thống mà vai cho phép. [2]
Quyền hạn cluster: Áp dụng trên toàn cluster, do vậy không thể phân chia những quyền này trên từng index trong cluster.
Ví dụ như:
Quyền hạn index: Áp dụng trên các index.
Ví dụ như:

3. Một số thao tác có sẵn​

- unlimited: Quyền thao tác cao nhất
- cluster_all: Quyền thao tác trên tất cả các cluster
- cluster_monitor: Cấp quyền giám sát tất cả các cluster
- indices_all: Cấp quyền thao tác trên tất cả các index của cluster
- read: Cấp quyền thao tác đọc index
- write: Cấp quyền ghi index

II. Tạo và phân quyền người dùng trong OpenSearch​

1. Tạo người dùng​

Người dùng được tạo tại mục "internal user" trong "Security", người dùng "user_reader" được tạo ra để đọc index.

2. Tạo vai​

Mục "Roles" trong Security cấp quyền "read", cho phép người dùng có vai này chỉ có thể đọc index về chỉ số

Sau khi vai được tạo ra, vào mục "Map user" cấp cho người dùng mới tạo trên

3. Kiểm tra kết quả​

Kiểm tra bằng cách trực tiếp truy vấn đến chỉ số cho phép, thấy được cả tài khoản admin và tài khoản đọc có thể truy cập

Nhưng khi truy vấn chỉ số không cho phép, chỉ tài khoản admin có thể truy vấn đến, còn tài khoản đọc chỉ trả về mã 403.

Do người dùng chỉ có thể đọc index, thao tác lọc index cho phép trên tạo "index pattern" sẽ tìm thấy.

Ngược lại, nếu tìm kiếm trên một index không cho phép sẽ không thấy

III. Hệ thống quản lí người dùng KPI SecurityZone của POPtech​

1. Các track trong hệ thống​

Theo thông tin lộ trình thực tập của POPtech, bao gồm 5 track chính:
- Infrastructure: Triển khai giải pháp liên quan hạ tầng và bảo mật như Network, SOC, SIEM…
- Marketing: Xây dựng các chiến lược Marketing, nghiên cứu thị trường, …
- Dev+DevOps: Xây dựng các sản phẩm như web, tool nội bộ…
- AI: Xây dựng các sản phẩm liên quan đến AI
- Sales: Bán các sản phẩm và giải pháp

2. Phân vai người dùng​

Người dùng trong đây sẽ được phân vai dựa trên 3 trường:
- Level: Cho biết người dùng đang giữ chức vụ nào
- Workspace: Cho biết bộ phận người dùng thuộc vào
- Team: Cho biết đội người dùng thuộc vào

3. Giới hạn từng quyền hạn​

- Người dùng thuộc Workspace nào thì chỉ có thể xem tất cả thành viên trong workspace đó.
- Phần Project, người dùng thuộc dự án nào thì chỉ thấy được dự án đó cùng với tất cả các thành phần tham gia.

IV. Index Policy và tối ưu tốc độ tìm kiếm​

1. Index Policy​

Là một tệp JSON miêu tả cách thức quản lí một index, bao gồm 3 thành phần [3]:
- state: Cho biết trạng thái của index, chứa tên và 2 thành phần còn lại

- actions: Những thao tác của chính sách có thể thực hiện khi index đi vào trạng thái cụ thể, sẽ có 2 trường quan trọng:
+ timeout: Thời gian cho phép để thực thi
+ retry: Sẽ được thực hiện khi quá thời gian timeout, chu kì thực hiện định nghĩa bởi số lần "count", khoảng cách lệch "backoff", giãn cách "delay".

- transitions: Sau khi thao tác được thực hiện, phần chuyển đổi trạng thái sẽ được kích hoạt cần 2 trường quan trọng:
+ state_name: Tên trạng thái mới
+ conditions: Điều kiện chuyển trạng thái, có thể là độ tuổi "min_*_age", kích thước "min_size" của index hoặc một tác vụ corn.

- Ngoài ra, còn có "Error notifications" gửi thông báo khi index thất bại.

2. Tối ưu tốc độ tìm kiếm​

2.1. Cấu hình mức độ index​

Index shard là thành phần quan trọng có thể ảnh hưởng đến tốc độ [4]. Cụ thể:
- Nếu quá nhiều shard kích thước nhỏ có thể làm cạn kiệt bộ nhớ khi lưu trữ metadata một cách không cần thiết.
- Nếu quá ít shard kích thước lớn sẽ khiến OpenSearch không thể phân bổ các yêu cầu trên toàn bộ domain.
Như vậy, để hiệu quả trong quản lí shard:
- Cần ít nhất một replica shards cho mỗi primary shard
- Đảm bảo mỗi shard có kích thước từ 10-30 GB trong trường hợp tìm kiếm với độ trễ thấp
- Đảm bảo mỗi shard có kích thước từ 30-50 GB trong trường hợp các khối lượng công việc thiên về thao tác ghi

2.2. Sử dụng bộ nhớ đệm​

OpenSearch dựa vào các loại bộ nhớ đệm trên heap khác nhau để tăng tốc độ truy xuất dữ liệu, qua đó cải thiện đáng kể độ trễ tìm kiếm. Theo mặc định, bộ nhớ đệm có thể lưu trữ tối đa 10.000 truy vấn và chiếm 10% tổng dung lượng vùng nhớ heap. [5]

Hiệu năng của OpenSearch có thể bị ảnh hưởng nếu kích thước bộ nhớ đệm truy vấn node quá nhỏ, vì một số truy vấn có thể không được lưu vào bộ nhớ đệm.

Có thể điều chỉnh tham số thiết lập chung "indices.queries.cache.size", tham số này chấp nhận giá trị dạng phần trăm như 5% hoặc giá trị cụ thể như 512MB.

Tài liệu tham khảo​

[1] OpenSearch, "Access control", OpenSearch Documents. Available: https://docs.opensearch.org/latest/security/access-control/index/
[2] OpenSearch, "Security permissions", OpenSearch Documents. Available: https://docs.opensearch.org/latest/security/access-control/permissions/
[3] OpenSearch, "ISM policies", OpenSearch Documents. Available: https://docs.opensearch.org/latest/im-plugin/ism/policies/
[4] "Chris Sharkey, Ron Miller", "Optimize OpenSearch index shard sizes", OpenSearch blog. Available: https://opensearch.org/blog/optimize-opensearch-index-shard-size/
[5] Noam Schwartz, "Bolster OpenSearch performance with 5 simple steps", Medium. Available: https://medium.com/data-science/bolster-opensearch-performance-with-5-simple-steps-ca7d21234f6b