Cách Hợp lý hóa Zero Trust bằng Shared Signals Framework

Zero Trust giúp các tổ chức thu hẹp bề mặt tấn công và phản ứng nhanh hơn với các mối đe dọa, nhưng nhiều tổ chức vẫn gặp khó khăn trong việc triển khai vì các công cụ bảo mật của họ không chia sẻ tín hiệu một cách đáng tin cậy. 88% tổ chức thừa nhận họ đã gặp phải những thách thức đáng kể khi cố gắng thực hiện các phương pháp tiếp cận như vậy, theo Accenture. Khi các sản phẩm không thể giao tiếp, các quyết định truy cập theo thời gian thực sẽ bị phá vỡ.
Minh họa Shared Signals Framework

Zero Trust giúp các tổ chức thu hẹp bề mặt tấn công và phản ứng nhanh hơn với các mối đe dọa, nhưng nhiều tổ chức vẫn gặp khó khăn trong việc triển khai vì các công cụ bảo mật của họ không chia sẻ tín hiệu một cách đáng tin cậy. 88% tổ chức thừa nhận họ đã gặp phải những thách thức đáng kể khi cố gắng thực hiện các phương pháp tiếp cận như vậy, theo Accenture. Khi các sản phẩm không thể giao tiếp, các quyết định truy cập theo thời gian thực sẽ bị phá vỡ.

Shared Signals Framework (SSF) nhằm mục đích khắc phục vấn đề này bằng một phương pháp tiêu chuẩn hóa để trao đổi các sự kiện bảo mật. Tuy nhiên, việc áp dụng vẫn chưa đồng đều. Ví dụ, Kolide Device Trust hiện không hỗ trợ SSF.

Scott Bean, Kỹ sư IAM và Bảo mật cấp cao tại MongoDB, đã đề xuất một cách giải quyết vấn đề, mang đến cho các nhóm một phương pháp dễ dàng và trực quan để vận hành SSF trong toàn bộ môi trường của họ.

Trong hướng dẫn này, chúng tôi sẽ chia sẻ tổng quan về workflow, cùng với hướng dẫn từng bước để triển khai và vận hành.

Vấn đề – Các công cụ IAM không hỗ trợ SSF

Một yêu cầu cốt lõi của Zero Trust là các tín hiệu liên tục, đáng tin cậy về trạng thái người dùng và thiết bị. Nhưng nhiều công cụ không hỗ trợ SSF cho Continuous Access Evaluation Protocol (CAEP), khiến việc chia sẻ hoặc hành động dựa trên các tín hiệu này trở nên khó khăn.

Các nhóm thường đối mặt với ba thách thức:

  • Các công cụ thiếu hỗ trợ SSF gốc
  • Các tín hiệu yêu cầu làm phong phú hoặc tương quan
  • Quản lý các endpoint SSF và xử lý token làm tăng chi phí

Nếu không có khả năng tương tác này, các tổ chức sẽ gặp khó khăn trong việc áp dụng các chính sách nhất quán — và trong các trường hợp như Kolide Device Trust, các sự kiện thiết bị quan trọng không bao giờ đến được các hệ thống như Okta.

Giải pháp – một bộ phát SSF biến các vấn đề của Kolide thành sự kiện CAEP

Vì SSF được xây dựng trên các yêu cầu HTTPS, tiêu chuẩn OpenID hoạt động với HTTP Action của Tines.

Scott đã phát triển một workflow mới tích hợp Kolide Device Trust với Tines, cho phép nó gửi tín hiệu SSF đến Okta. Nếu một thiết bị không tuân thủ, Kolide sẽ gửi một thông báo đến workflow thông qua webhook. Tines làm phong phú tín hiệu, đảm bảo nó có thể được liên kết với người dùng, xây dựng một Security Event Token (SET), và sau đó gửi nó đến Okta.

Theo cách này, Tines đóng vai trò là cầu nối giúp SSF hoạt động trên môi trường IT phân tán, ngay cả khi các công cụ riêng lẻ không hỗ trợ tiêu chuẩn này một cách tự nhiên.

Tines có thể:

  • Nhận tín hiệu từ Kolide (và các công cụ tương tự) qua webhook khi một thiết bị trở nên không tuân thủ
  • Làm phong phú và tương quan các tín hiệu đó (ví dụ: ánh xạ thiết bị với người dùng)
  • Tạo và ký SET đáp ứng đặc tả SSF
  • Gửi chúng đến Okta (và các nhà cung cấp danh tính khác) để thực thi Zero Trust
  • Lưu trữ các endpoint metadata SSF cần thiết bằng cách sử dụng tiền tố đường dẫn API, cung cấp cho các hệ thống tiêu thụ một nơi tuân thủ tiêu chuẩn để tìm nạp khóa và giải mã token

Tất cả những điều này giúp việc thực thi Zero Trust nhanh hơn, đáng tin cậy hơn và dễ vận hành hơn nhiều. Các nhóm IT được trao quyền đánh giá rủi ro thiết bị liên tục, theo thời gian thực, phản ứng nhanh hơn với các mối đe dọa và điều phối chính sách linh hoạt hơn. Và người dùng cuối nhận được lợi ích từ việc khắc phục tự động, giúp tối ưu hóa năng suất và giảm thiểu sự can thiệp của IT.

Nếu bạn muốn tìm hiểu sâu hơn về hiện đại hóa danh tính, hướng dẫn IAM của Tines khám phá cách các nhóm đang hợp nhất tin cậy thiết bị, quyết định truy cập và thực thi đặc quyền tối thiểu bằng tự động hóa. Workflow của Scott là một trong số các mô hình thực tế bên trong.

Tổng quan về workflow

Các công cụ cần thiết:

  • Tines – nền tảng điều phối workflow và AI
  • Kolide – giám sát tin cậy và trạng thái thiết bị
  • Okta – nền tảng danh tính nhận sự kiện CAEP

Các thông tin xác thực cần thiết:

  • Tines API Key - có phạm vi `Team` với vai trò `Editor`
  • Kolide API Key - Read Only
  • Kolide Webhook Signing Secret

Các tài nguyên cần thiết:

Tên miền Okta, chẳng hạn như example.okta.com, example.oktapreview.com hoặc tên miền tùy chỉnh của bạn.

Cách thức hoạt động:

Workflow này tạo ra một bộ phát SSF proof-of-concept có thể được đăng ký với Okta và gửi các sự kiện CAEP thay đổi tuân thủ thiết bị (được gửi dưới dạng SET) dựa trên các vấn đề được tạo trong Kolide. Có ba yếu tố:

1. Tạo và lưu trữ khóa ký SET (SET là các JSON Web Token đã ký):

  • Tạo một cặp khóa RSA và chuyển đổi nó sang định dạng JWK.
  • Công bố khóa công khai để các bộ thu SSF xác thực chữ ký SET.
  • Lưu trữ khóa JWK riêng tư dưới dạng secret của Tines.

2. Hiển thị SSF transmitter API

Các bộ thu SSF (như Okta) cần:

  • một endpoint .well-known/sse-configuration mô tả bộ phát
  • một endpoint JWK hiển thị khóa công khai được sử dụng để xác minh chữ ký SET
  • một trigger webhook hoạt động như bề mặt API của SSF
  • logic trả về cấu hình .well-known
  • logic trả về các JWK

Khi điều này hoạt động, các nhóm có thể đăng ký một bộ thu SSF mới trong Okta tại:

  • Security → Device Integrations → Receive shared signals

Và tạo một stream mới bằng URL của API và endpoint `.well-known` mới.

3. Tạo, ký và gửi SET từ các sự kiện của Kolide

  • Nhận các sự kiện issue của Kolide qua webhook và xác thực chúng bằng secret ký.
  • Tìm nạp metadata thiết bị và người dùng từ Kolide.
  • Xây dựng một SET cho sự kiện CAEP Device Compliance Change.
  • Ký SET bằng khóa riêng tư đã lưu trữ trước đó bằng cách sử dụng công thức JWT_SIGN.
  • Gửi token đã ký cuối cùng đến endpoint security-events của Okta.

Điều này cung cấp các bản cập nhật tuân thủ thiết bị theo thời gian thực cho Okta để các chính sách truy cập có thể phản ứng ngay lập tức.

Cấu hình workflow — hướng dẫn từng bước

Bạn có thể xây dựng và chạy toàn bộ workflow này bằng Tines Community Edition.

Sơ đồ workflow Tines

1. Đăng nhập vào Tines hoặc tạo tài khoản mới.

2. Điều hướng đến workflow dựng sẵn trong thư viện. Chọn nhập. Thao tác này sẽ đưa bạn thẳng đến workflow dựng sẵn mới của bạn.

Giao diện Tines workflow

3. Thu thập các thông tin xác thực cần thiết

  • Tines API Key (có phạm vi team với vai trò Editor)
  • Kolide API Key (chỉ đọc)
  • Kolide Webhook Signing Secret

Những thông tin này đảm bảo các cuộc gọi được xác thực đến Kolide và xác thực webhook an toàn.

4. Thu thập các tài nguyên cần thiết của bạn

Bạn sẽ cần một tên miền Okta tenant, chẳng hạn như:

  • example.oktapreview.com
  • example.okta.com
  • hoặc tên miền thương hiệu Okta tùy chỉnh của bạn

Tên miền này được sử dụng khi gửi các SET đã ký đến endpoint security-events của Okta.

Lưu ý: Trong ví dụ được cung cấp, Scott đã thiết lập dưới dạng nhà cung cấp `push` thay vì `poll` vì các token được gửi dựa trên các webhook đến, do đó không cần lưu trữ trạng thái.

5. Tạo khóa ký SET của bạn

  • Sử dụng hành động Generate JWK keyset để tạo khóa RSA
  • Chuyển đổi cả khóa công khai và khóa riêng tư sang định dạng JWK (hai lần biến đổi sự kiện)
  • Lưu trữ keyset kết quả bằng cách sử dụng secret của Tines

Điều này là bắt buộc trước khi Okta chấp nhận và xác minh các SET của bạn.

6. Công bố SSF transmitter API

Webhook SSF API chứa hai nhánh:

  • Endpoint .well-known
    • Trigger: well-known
    • Event transform: trả về cấu hình SSF khai báo khả năng của bộ phát
  • Endpoint JWKS
    • Trigger: JWKs
    • Event transform: trả về các JWK công khai để Okta có thể xác minh chữ ký

Sau khi hoạt động, Okta có thể đăng ký bộ phát này làm người gửi tín hiệu được chia sẻ.

7. Kết nối Kolide và xử lý các vấn đề của thiết bị

Luồng tích hợp Kolide tuân theo các bước sau:

  • Webhook: Kolide webhook – nhận các sự kiện issue opened/resolved
  • Get device details – tìm nạp metadata cho thiết bị liên quan
  • Device has a user – logic phân nhánh để xác nhận người dùng được liên kết
  • Get user details – tra cứu metadata người dùng cho payload CAEP

Tùy thuộc vào việc vấn đề là mới hay đã được giải quyết:

  • Build SET – xây dựng sự kiện CAEP device_compliance_change
  • Sign SET – sử dụng khóa riêng tư RSA đã lưu trữ trước đó để tạo SET tuân thủ SSF
  • Send SET – gửi token đã ký cuối cùng đến endpoint security-events của Okta

Điều này cung cấp các bản cập nhật tuân thủ thiết bị theo thời gian thực cho Okta để các chính sách truy cập có thể phản ứng ngay lập tức.

Tổng hợp lại

SSF tồn tại để giúp các công cụ bảo mật nói cùng một ngôn ngữ, cung cấp cái nhìn sâu sắc liên tục về rủi ro và trạng thái thiết bị. Nhưng khi các công cụ chính không hỗ trợ tiêu chuẩn, các khoảng trống xuất hiện và các chính sách truy cập bị tụt hậu so với những thay đổi trong thế giới thực.

Tines lấp đầy những khoảng trống này bằng cách kích hoạt các workflow thông minh mới. Chúng đảm bảo rằng ngay cả các công cụ không hỗ trợ SSF cũng có thể gửi thông tin theo cùng một cách tiêu chuẩn hóa. Bằng cách sử dụng Tines để tạo, ký và gửi các tín hiệu tuân thủ theo thời gian thực, bạn nhận được lợi ích của SSF ngay cả khi công cụ nguồn không được xây dựng cho mục đích đó.

Nếu bạn muốn tự mình thử workflow này, bạn có thể thiết lập nó trong vài phút với một tài khoản Tines miễn phí. Và nếu bạn muốn xem cách trạng thái thiết bị phù hợp với chiến lược danh tính rộng hơn, hướng dẫn về các workflow IAM hiện đại này cung cấp các mô hình thực tế và các workflow trong thế giới thực như của Scott mà bạn có thể bắt đầu xây dựng ngay hôm nay.