Tuân thủ và bảo mật API: Các yêu cầu về bảo vệ dữ liệu

Giới thiệu

Việc chứng minh tuân thủ các quy định bảo vệ dữ liệu từ trước đến nay thường đòi hỏi nhiều công sức và nguồn lực để đối phó với các rủi ro quen thuộc. Tuy nhiên, điều này đang thay đổi. Bề mặt tấn công ngày nay phát triển nhanh chóng, bao gồm cả những mối đe dọa mà hầu hết các chương trình tuân thủ doanh nghiệp chưa thể lường hết. Một phần nguyên nhân là do các cơ quan quản lý cũng không luôn bắt kịp và đưa ra hướng dẫn rõ ràng về mọi khía cạnh cần thiết để ngăn chặn vi phạm.

Đây cũng là trường hợp của bảo vệ API. Mỗi khi khách hàng, đối tác hoặc nhà cung cấp tương tác với doanh nghiệp của bạn trên nền tảng số, luôn có một API hoạt động phía sau để hỗ trợ trao đổi thông tin nhanh chóng, thường bao gồm dữ liệu nhạy cảm. Kẻ tấn công nay đã nhận ra rằng chúng có thể đơn giản hóa chiến lược đánh cắp dữ liệu bằng cách nhắm trực tiếp vào các API.

Bạn có thể đã thấy những quy định mới đề cập đến việc kiểm kê, đánh giá hoặc bảo mật API. Tuy nhiên, ngay cả khi không có ngôn từ cụ thể về API, việc chúng trở thành một điểm tấn công rõ ràng cũng đồng nghĩa với việc cần có biện pháp bảo vệ phù hợp.

Việc API trở thành một vấn đề quan trọng trong tuân thủ không có gì đáng ngạc nhiên. Các API bị lộ hoặc cấu hình sai rất phổ biến, dễ bị tấn công và thường không được bảo vệ đầy đủ. Chỉ một API bị xâm nhập cũng có thể dẫn đến việc đánh cắp hàng triệu bản ghi dữ liệu. Những con số thực tế đã nói lên tất cả:

• 78% tổ chức đã từng gặp sự cố bảo mật API.
• 44% đã bị cơ quan quản lý xử phạt do các sự cố bảo mật API.

Điều này ảnh hưởng thế nào đến chương trình tuân thủ của bạn? Các cơ quan quản lý cần thấy rằng tổ chức của bạn đang thực hiện các biện pháp bảo vệ mọi điểm truy cập vào dữ liệu nhạy cảm. Điều đó có nghĩa là bạn cần chứng minh rằng tổ chức của mình có thể:

• Kiểm kê tất cả API, bao gồm cả các API ẩn (shadow API)
• Phát hiện và khắc phục mọi lỗ hổng API
• Áp dụng các biện pháp kiểm soát phù hợp để ngăn chặn rò rỉ dữ liệu qua API

Bài viết này phân tích bản chất của các rủi ro API ngày càng gia tăng, nêu bật sáu quy định và khung pháp lý yêu cầu bảo vệ API (dù trực tiếp hay gián tiếp) và đưa ra lời khuyên về cách đáp ứng các yêu cầu tuân thủ thông qua các phương pháp bảo mật API hiệu quả.

Hiểu về rủi ro API

API đóng vai trò cốt lõi trong các sản phẩm, dịch vụ số và môi trường đám mây của doanh nghiệp. Việc API liên tục truy cập dữ liệu vừa mang lại lợi ích doanh thu vừa tiềm ẩn rủi ro vận hành. Tuy nhiên, hầu hết các doanh nghiệp – ngay cả những doanh nghiệp có chương trình bảo mật tiên tiến – vẫn chưa ưu tiên các mối đe dọa liên quan đến API ở mức độ như họ tập trung vào các mối đe dọa khác như lừa đảo (phishing) hay mã độc tống tiền (ransomware).

Một số tổ chức dựa vào cổng API (API gateway) và tường lửa ứng dụng web (WAF) để bảo vệ API ở mức cơ bản. Tuy nhiên, các công cụ này không được thiết kế để cung cấp khả năng quan sát toàn diện, bảo vệ theo thời gian thực và kiểm tra liên tục như các giải pháp bảo mật API chuyên biệt. Dưới đây là lý do vì sao chúng không đủ:

• API gateway và WAF chỉ có thể giám sát lưu lượng API đã được quản lý và đi qua chúng.
• Chúng không thể bảo vệ các API chưa được quản lý, trong khi các chuyên gia dự báo rằng đến năm 2025, những API này sẽ chiếm gần một nửa hệ sinh thái API của một doanh nghiệp điển hình.
• Do đó, các nhóm bảo mật chưa sẵn sàng bảo vệ phần bề mặt tấn công phát triển nhanh nhất, vì họ thiếu thông tin về đường đi của API, cách chúng được cấu hình, loại dữ liệu nhạy cảm được trao đổi và những rủi ro tiềm ẩn.

Bảo vệ thông tin người dùng là ưu tiên của các cơ quan quản lý, và họ áp dụng mức phạt nghiêm khắc đối với các công ty không bảo vệ dữ liệu khách hàng khỏi truy cập trái phép. Chỉ 4 trong 10 chuyên gia bảo mật có danh sách đầy đủ API biết được API nào trả về dữ liệu nhạy cảm, trong khi nhiều yêu cầu API thực chất đến từ kẻ tấn công tìm cách khai thác lỗ hổng. Điều này cho thấy các vụ rò rỉ dữ liệu qua API sẽ còn gia tăng, đặc biệt khi các cuộc tấn công API hiện nay vẫn rất dễ thực hiện.

Bốn cuộc tấn công API ảnh hưởng đến tuân thủ

Một vụ tấn công API có thể ảnh hưởng đến việc tuân thủ của doanh nghiệp như thế nào? Dưới đây là một số ví dụ:

• Một ứng dụng quản lý dự án phổ biến đã bị tấn công khi kẻ xâm nhập khai thác một điểm cuối API không có cơ chế xác thực. API bị xâm phạm cho phép truy cập trái phép vào thông tin của hàng triệu người dùng. Vài tháng sau, hơn 21 GB dữ liệu, bao gồm địa chỉ email và thông tin thành viên nhóm, đã bị rò rỉ trên internet.
• Hơn 11 triệu hồ sơ khách hàng của một công ty viễn thông lớn đã bị lộ, được cho là do một API vô tình bị mở công khai trên internet mà không có cơ chế xác thực. Kẻ tấn công đã khai thác API này, phát hiện nó không có mã định danh duy nhất, sau đó đoán số ID và dễ dàng truy xuất dữ liệu nhạy cảm.
• Một công ty mạng xã hội đã bị tấn công hai lần trong những năm gần đây do lạm dụng API, tạo điều kiện cho kẻ xấu thu thập dữ liệu (scraping). Lần đầu, dữ liệu cá nhân từ 500 triệu hồ sơ người dùng bị trích xuất và rao bán. Lần thứ hai, kẻ tấn công tạo ra một cơ sở dữ liệu chứa số điện thoại và thông tin lương của 700 triệu người dùng.
• Cùng một kỹ thuật này đã được sử dụng để đánh cắp dữ liệu của hàng triệu người dùng từ một công ty mạng xã hội khác. Do một nhà cung cấp bên thứ ba lợi dụng API của công ty để thu thập dữ liệu nhạy cảm, doanh nghiệp này đã bị phạt 5 tỷ USD. Dù API bị lạm dụng bởi bên thứ ba, công ty vẫn chịu trách nhiệm vì không giám sát chặt chẽ ứng dụng của mình.

Sáu ví dụ về quy định và khung pháp lý yêu cầu bảo mật API

Trong nhiều quy định và khung pháp lý, API không nhất thiết được nhắc đến trực tiếp, nhưng các yêu cầu đều nhấn mạnh việc bảo vệ ứng dụng và hạ tầng mà API vận hành. Ví dụ:

• Tiêu chuẩn Bảo mật Dữ liệu Ngành Thẻ Thanh toán (PCI DSS) v4.0 đưa ra hướng dẫn để đảm bảo phần mềm của tổ chức sử dụng an toàn các thành phần bên ngoài, bao gồm cả API truyền dữ liệu thanh toán từ ứng dụng di động đến hệ thống ngân hàng.
• Khung phát triển phần mềm an toàn của NIST cung cấp hướng dẫn về việc tạo phần mềm được bảo vệ tốt, duy trì bảo mật liên tục và xử lý các lỗ hổng. API đóng vai trò cốt lõi trong quá trình phát triển phần mềm.

Trong nhiều trường hợp, các quy định đưa ra mục tiêu bảo mật dữ liệu một cách chung chung, như yêu cầu về “các biện pháp bảo mật phù hợp” trong Quy định Bảo vệ Dữ liệu Chung (GDPR). API của bạn có thể nhận hàng triệu yêu cầu mỗi ngày, từ cả khách hàng lẫn kẻ tấn công. Doanh nghiệp cần xác định các biện pháp bảo mật cần thiết và chứng minh cách chúng hoạt động.

Hãy cùng xem xét kỹ hơn các quy định và khung pháp lý có tác động trực tiếp đến hệ sinh thái API của bạn.

1. PCI DSS v4.0

Được phát triển bởi Hội đồng Bảo mật Dữ liệu Ngành Thẻ Thanh toán, PCI DSS đã trở thành tiêu chuẩn toàn cầu về bảo vệ dữ liệu thanh toán. Nếu doanh nghiệp của bạn chấp nhận thẻ tín dụng và thực hiện xử lý, lưu trữ hoặc truyền dữ liệu chủ thẻ điện tử, bạn phải tuân thủ tiêu chuẩn này.

Các yêu cầu trong phiên bản gốc của PCI DSS vẫn giữ nguyên tầm quan trọng kể từ khi được ban hành vào năm 2006, bao gồm việc cấp quyền truy cập vào hệ thống và dữ liệu chủ thẻ dựa trên nguyên tắc cần biết, cũng như xác định yêu cầu truy cập theo từng vai trò.

Tuy nhiên, với PCI DSS v4.0 có hiệu lực, các doanh nghiệp cần điều chỉnh chương trình tuân thủ của mình để đối phó với các mối đe dọa ngày càng nhắm vào hàng nghìn API trong công nghệ thanh toán. Nhìn chung, PCI DSS v4.0 tập trung vào bốn mục tiêu chính:

• Đáp ứng liên tục các yêu cầu bảo mật của ngành thanh toán
• Khuyến khích bảo mật như một quá trình liên tục
• Cung cấp sự linh hoạt cho doanh nghiệp (ví dụ: công cụ mới, biện pháp kiểm soát mới) trong việc đáp ứng yêu cầu
• Nâng cao các phương pháp và quy trình xác thực

Yêu cầu 6.2.3 của PCI DSS v4.0 nhấn mạnh việc các tổ chức phải rà soát mã nguồn tùy chỉnh (được phát triển bởi nhà cung cấp bên thứ ba nhưng không phải là ứng dụng thương mại sẵn có) để đảm bảo không có lỗ hổng nào được đưa vào môi trường sản xuất. Đối với API, yêu cầu này hướng dẫn doanh nghiệp đảm bảo phần mềm sử dụng an toàn các thành phần bên ngoài như thư viện, framework và API. Những quy định như vậy cho thấy vai trò quan trọng của API trong chuỗi cung ứng phần mềm rộng lớn hơn và các biện pháp cần thiết để bảo vệ chúng.

API đã trở thành phương thức mặc định để kết nối và trao đổi dữ liệu trong môi trường ứng dụng hiện đại. Vì vậy, bảo mật API từ giai đoạn trước khi triển khai (shift-left) đến sau khi đưa vào hoạt động (shield-right) là yếu tố quan trọng giúp doanh nghiệp số chống lại các cuộc tấn công. Dưới đây là một số phương pháp bảo mật API tốt nhất để tuân thủ yêu cầu 6.2.3:

• Xác minh việc sử dụng các thành phần API và mức độ bảo mật của chúng (ví dụ: phát hiện cấu hình sai dẫn đến lỗ hổng, bao gồm cả việc sử dụng mã hóa yếu).
• Xác thực hành vi bình thường và mong đợi của API, đồng thời triển khai các biện pháp kiểm soát để chặn các tác nhân đáng ngờ lợi dụng hệ thống (ví dụ: giám sát hành vi của ứng dụng để phát hiện lỗ hổng logic).
• Phát hiện các framework bên thứ ba được sử dụng trong API của bạn, xác định những framework đã lỗi thời và có nguy cơ bị tấn công.
• Xây dựng danh sách đầy đủ tất cả API, bao gồm các phiên bản đang chạy; điều này giúp phát hiện các lỗ hổng tiềm ẩn và những tính năng chưa được tài liệu hóa mà bạn cần quản lý.
• Xác thực tính bảo mật của mã nguồn API và đảm bảo không đưa bất kỳ lỗ hổng nào liên quan đến API vào môi trường sản xuất.
• Áp dụng các phương pháp lập trình an toàn cho API, giúp doanh nghiệp triển khai mã một cách bảo mật và liên tục theo hướng tiếp cận có hệ thống.

2. Quy định chung về bảo vệ dữ liệu (GDPR)

GDPR là một bộ luật của Liên minh Châu Âu (EU) nhằm tăng cường và thống nhất việc bảo vệ dữ liệu cá nhân của công dân EU. Tuy nhiên, quy định này không chỉ áp dụng cho các công ty có trụ sở tại EU mà còn bắt buộc đối với mọi tổ chức cung cấp hàng hóa hoặc dịch vụ cho người tiêu dùng tại EU.

Quy định này xác định dữ liệu cá nhân là thông tin có thể liên kết hoặc nhận diện một cá nhân. Dữ liệu thuộc phạm vi điều chỉnh của GDPR có thể bao gồm tên, thông tin liên hệ, dữ liệu tài chính, y tế của cá nhân. Về mặt kỹ thuật, dữ liệu được bảo vệ cũng bao gồm thông tin vị trí địa lý như địa chỉ IP và cookie trên web.

Điều này có ý nghĩa gì đối với bảo mật API? Dù bạn đang phát triển ứng dụng, microservices hay thiết bị Internet vạn vật (IoT), các API đóng vai trò cốt lõi trong những công nghệ này thường trao đổi dữ liệu thuộc phạm vi GDPR. Do đó, các tổ chức phát triển API có thể truy cập từ internet phải tích hợp biện pháp bảo vệ dữ liệu ngay từ giai đoạn thiết kế, thay vì bổ sung sau khi triển khai.

Hãy áp dụng nguyên tắc tối thiểu quyền (least privilege), đảm bảo người dùng chỉ có các quyền cần thiết để thực hiện công việc của họ.

Điều 25 của GDPR dựa trên nguyên tắc tối thiểu quyền, yêu cầu các công ty thực hiện “các biện pháp kỹ thuật và tổ chức để đảm bảo rằng, theo mặc định, chỉ những dữ liệu cá nhân cần thiết cho từng mục đích cụ thể mới được xử lý.” Do đó, các nhà phát triển API cần triển khai cơ chế xác thực và ủy quyền người dùng để bảo vệ dữ liệu nhạy cảm trong API. Đồng thời, các nhóm phát triển API phải đảm bảo dữ liệu luôn được bảo mật trong quá trình truyền tải bằng cách sử dụng các giao thức giao tiếp an toàn để mã hóa thông tin giữa máy khách và máy chủ.

Tuy nhiên, còn hệ thống API hiện có mà các tổ chức đã xây dựng trong nhiều năm, thậm chí hàng thập kỷ qua thì sao? Một phần lớn API trong doanh nghiệp không được quản lý, bị lãng quên hoặc hoạt động liên tục mà không qua kiểm soát. Trong những trường hợp này, để tuân thủ GDPR, các tổ chức cần:

• Xác định tất cả API trong hệ thống CNTT của doanh nghiệp
• Đánh giá các yếu tố rủi ro (ví dụ: loại dữ liệu mà API trao đổi và đối tượng có thể truy cập dữ liệu đó)
• Khắc phục các lỗ hổng, bao gồm cấu hình sai hoặc cơ chế xác thực yếu
• Kiểm tra API liên tục để đảm bảo khả năng chống lại cả các phương thức tấn công truyền thống và mới xuất hiện

3. Đạo luật Khả năng phục hồi Hoạt động Kỹ thuật số (DORA)

Với vai trò là một lĩnh vực hạ tầng quan trọng, ngành tài chính EU cần đáp ứng các yêu cầu của DORA để có thể chống chịu và phục hồi sau các cuộc tấn công mạng. DORA thiết lập một khung quản lý rủi ro toàn diện và bắt buộc đối với công nghệ thông tin và truyền thông (ICT). Đạo luật này nhằm hài hòa và siết chặt các yêu cầu đối với các công ty tài chính trong EU, giúp đơn giản hóa bối cảnh pháp lý vốn đang bị phân tán bởi nhiều quy định và tiêu chuẩn khác nhau.

Tổng cộng, hơn 22.000 tổ chức tài chính và nhà cung cấp dịch vụ CNTT tại EU chịu sự ảnh hưởng của DORA. Đáng chú ý, điều này bao gồm cả các bên thứ ba cung cấp hệ thống và dịch vụ CNTT cho các công ty tài chính EU, bao gồm cả nhà cung cấp dịch vụ đám mây. Đạo luật yêu cầu các tổ chức tài chính xây dựng chiến lược quản lý rủi ro đối với bên thứ ba trong lĩnh vực CNTT và thực hiện thẩm định để đánh giá mức độ phù hợp của các nhà cung cấp.

DORA đưa ra nhiều yêu cầu liên quan đến bảo mật API, bao gồm tính ổn định hoạt động kỹ thuật số. Điều này buộc các tổ chức phải triển khai các chương trình kiểm tra định kỳ nhằm xác định lỗ hổng, điểm yếu và các thiếu sót trong hoạt động kỹ thuật số. Các bài kiểm tra có thể bao gồm kiểm tra an ninh mạng, kiểm thử xâm nhập, kiểm tra ứng dụng web, v.v. Đặc biệt, các tổ chức tài chính cần thực hiện các đánh giá bắt buộc dựa trên kiểm thử xâm nhập theo hướng đe dọa (TLPT), tùy theo quy mô, mức độ rủi ro và đặc điểm kinh doanh của họ. Bên cạnh đó, việc kiểm tra API thường xuyên để phát hiện lỗ hổng cũng quan trọng không kém.

DORA đưa ra các ví dụ về kiểm thử bảo mật, bao gồm kiểm tra ứng dụng web và API. Điều này bao gồm việc sử dụng các nguồn tài nguyên công khai như Dự án Bảo mật Ứng dụng Mở Toàn cầu (OWASP). Đặc biệt, danh sách OWASP Top 10 API Security Risks giúp các tổ chức xác định các lỗi cấu hình, điểm yếu, sai sót logic và vấn đề trong mã nguồn, từ đó ngăn chặn kẻ tấn công truy cập, thao túng hoặc kiểm soát tài nguyên của doanh nghiệp.

4. Đạo luật Bảo hiểm Y tế, Khả năng Di chuyển và Trách nhiệm Giải trình (HIPAA)

HIPAA tập trung vào các quy tắc bảo mật và quyền riêng tư dữ liệu nhằm bảo vệ thông tin y tế được bảo vệ (PHI) trong hồ sơ y tế điện tử (EHR), nền tảng nhập lệnh điện tử của bác sĩ và các hệ thống CNTT y tế khác. Mọi nhà cung cấp dịch vụ y tế, quản trị viên kế hoạch hoặc tổ chức trung gian tại Hoa Kỳ lưu trữ hoặc truyền PHI dưới dạng điện tử đều phải tuân thủ HIPAA. Điều này bao gồm việc đảm bảo tính bảo mật, toàn vẹn và khả dụng của PHI, đồng thời bảo vệ dữ liệu khỏi truy cập trái phép và sử dụng sai mục đích.

HIPAA là một ví dụ về quy định có ảnh hưởng lớn đến API, ngay cả khi nó không đề cập trực tiếp đến API trong các yêu cầu của mình.

Hãy xem xét một nhà cung cấp công nghệ phát triển cổng thông tin bệnh nhân cho các phòng khám chăm sóc sức khỏe 24/7. Một chức năng cốt lõi của các cổng này là cung cấp cho bệnh nhân quyền truy cập nhanh chóng và an toàn vào dữ liệu về lịch sử khám bệnh, kết quả xét nghiệm, thanh toán và nhiều thông tin khác. API đóng vai trò trung gian cho quá trình trao đổi này. Cả phòng khám và nhà cung cấp công nghệ đều phải tuân thủ các yêu cầu của HIPAA.

Quy tắc quyền riêng tư của HIPAA quy định rằng các đơn vị chịu sự quản lý "phải xây dựng và thực hiện các chính sách và quy trình nhằm hạn chế quyền truy cập và sử dụng thông tin y tế được bảo vệ dựa trên vai trò cụ thể của các thành viên trong tổ chức." Do đó, các nhà phát triển API của tổ chức phải tích hợp các biện pháp bảo vệ kỹ thuật như xác thực, ID người dùng duy nhất và kiểm soát truy cập theo vai trò để đảm bảo nguyên tắc ít đặc quyền nhất được áp dụng.

Khả năng giám sát cũng là yếu tố quan trọng đối với các tổ chức chịu sự quản lý của HIPAA, dù là nhà cung cấp dịch vụ có đội ngũ IT phát triển API tùy chỉnh hay nhà cung cấp phần mềm xây dựng API cho đơn vị đó. Các tổ chức cần đánh giá và báo cáo theo thời gian thực về mức độ rủi ro của từng API, bao gồm loại thông tin y tế được bảo vệ (PHI) mà chúng truyền tải. Điều này không chỉ liên quan đến việc tuân thủ mà còn giúp đáp ứng yêu cầu của HIPAA về việc phản hồi các cá nhân khi họ yêu cầu thông tin về thời gian, địa điểm, lý do và đối tượng đã nhận PHI của họ.

5. Chỉ thị An ninh mạng và Hệ thống Thông tin (NIS2)

Liên minh Châu Âu đã thông qua phiên bản 2.0 của Chỉ thị NIS vào tháng 1 năm 2023, mở rộng các hướng dẫn của phiên bản gốc về bảo mật hạ tầng CNTT và báo cáo sự cố. Mặc dù phiên bản 2.0 không đề cập cụ thể đến API, nhưng các yêu cầu của nó có tác động quan trọng đến việc bảo vệ và quản lý API, do API đóng vai trò cốt lõi trong nhiều dịch vụ kỹ thuật số của các tổ chức chịu sự điều chỉnh của chỉ thị này. Đáng chú ý, NIS2 bao gồm:

• Một phạm vi ngành rộng hơn — chẳng hạn như các nhà cung cấp dịch vụ đám mây và công ty truyền thông xã hội được bổ sung vào danh sách hiện có, bao gồm các nhà vận hành hạ tầng quan trọng. Đối với các lĩnh vực này, nơi API được sử dụng rộng rãi để tích hợp và cung cấp dịch vụ, đảm bảo an ninh API trở thành một ưu tiên hàng đầu.
• Một trọng tâm mới vào việc bảo vệ chuỗi cung ứng — các doanh nghiệp phải đánh giá rủi ro và đảm bảo an ninh cho chuỗi cung ứng CNTT cũng như mối quan hệ với các nhà cung cấp bên thứ ba. Vì API thường được sử dụng để tích hợp các dịch vụ bên ngoài, việc đảm bảo an toàn cho API là yếu tố then chốt để tuân thủ quy định
• Yêu cầu xây dựng hệ thống quản lý an ninh thông tin để đánh giá con người, chính sách và công nghệ nhằm bảo vệ các tài nguyên nhạy cảm và đảm bảo khả năng hoạt động liên tục. Vì API là một trong những vectơ tấn công phát triển nhanh, chúng phải được đưa vào chiến lược quản lý rủi ro.
• Báo cáo các sự cố an ninh mạng nghiêm trọng, bao gồm cả vi phạm API. Do đó, các tổ chức cần triển khai các cơ chế để giám sát, phát hiện và báo cáo các sự cố liên quan đến API.

6. Hướng dẫn dành cho cơ quan quản lý dịch vụ tài chính Hoa Kỳ

Hội đồng Kiểm tra các Tổ chức Tài chính Liên bang (FFIEC) thiết lập hướng dẫn và tiêu chuẩn để các cơ quan quản lý liên bang giám sát ngành tài chính Hoa Kỳ. Điều này bao gồm Cục Dự trữ Liên bang (Federal Reserve), FDIC, OCC và NCUA. Sứ mệnh của hội đồng là bảo vệ người tiêu dùng và nhà đầu tư khỏi gian lận, lạm dụng và hành vi sai trái. Mặc dù không phải là một quy định, nhưng hướng dẫn của FFIEC đóng vai trò quan trọng trong việc giúp các công ty tài chính hiểu cách tuân thủ các biện pháp bảo mật được khuyến nghị.

Đây là một ví dụ quan trọng về một tài liệu bao gồm hướng dẫn cụ thể về cách bảo vệ API và từ đó bảo vệ người tiêu dùng khỏi gian lận và trộm cắp danh tính. Dưới đây là tổng quan:

• Kiểm kê: FFIEC khuyến nghị xây dựng danh mục tất cả các hệ thống thông tin — bao gồm cả API — yêu cầu xác thực và kiểm soát truy cập. Điều này không chỉ áp dụng cho các tổ chức tài chính mà còn cho cả các bên thứ ba của họ, chẳng hạn như nhà cung cấp dịch vụ đám mây.
• Xác thực: API chỉ nên cho phép truy cập đối với người dùng được ủy quyền. Việc xác định tất cả người dùng (ví dụ: khách hàng) cần kiểm soát truy cập là rất quan trọng. Ngoài ra, cần xác định những người dùng yêu cầu các biện pháp kiểm soát nâng cao, chẳng hạn như xác thực đa yếu tố.
• Ủy quyền: API chỉ nên cho phép người dùng được ủy quyền truy cập vào các tài nguyên cụ thể. Theo đó, FFIEC khuyến nghị triển khai bảo mật nhiều lớp — ví dụ, giám sát, ghi log và báo cáo hoạt động để xác định và theo dõi các truy cập trái phép.
• Quản lý rủi ro: FFIEC xác định một số thực tiễn quản lý rủi ro hiệu quả trong hướng dẫn mới nhất của họ. Tuy nhiên, họ đặc biệt nhấn mạnh API trong danh mục Kiểm kê Hệ thống Thông tin, điều này có nghĩa là bạn cần có một danh mục API chính xác.

Một tổ chức có thể đã quen thuộc với các mối đe dọa phổ biến như phishing hoặc ransomware, nhưng FFIEC yêu cầu xác định bất kỳ mối đe dọa mạng nào có “khả năng hợp lý ảnh hưởng đến hệ thống thông tin của tổ chức tài chính” và dữ liệu của họ. Như đã đề cập trong phần giới thiệu, 78% tổ chức đã gặp sự cố bảo mật API, do đó, việc bảo vệ API sẽ trở thành một yêu cầu tuân thủ quan trọng khi các quy định tài chính tiếp tục phát triển.

Đáp ứng các thách thức tuân thủ với các biện pháp bảo vệ API theo phương pháp tốt nhất

Bối cảnh mối đe dọa ngày nay đòi hỏi một giải pháp bảo mật API toàn diện, bao gồm khám phá API, quản lý tư thế bảo mật, bảo vệ khi chạy và kiểm tra bảo mật API. Cách tiếp cận toàn diện này hoạt động như một phần bổ sung cho bất kỳ WAF hoặc cổng API nào đã được triển khai.

1. Khám phá API

Không hiếm trường hợp có những API mà không ai biết đến. Hầu hết các tổ chức có rất ít hoặc không có khả năng giám sát một phần lớn lưu lượng API của họ, thường là do giả định rằng tất cả API đều được định tuyến qua một API gateway. Nhưng thực tế không phải vậy. Doanh nghiệp của bạn sẽ phải đối mặt với nhiều rủi ro nếu không có một danh mục API đầy đủ và chính xác.

Các năng lực cốt lõi cần có:

• Xác định vị trí và lập danh mục tất cả API của bạn, bất kể cấu hình hoặc loại API nào
• Phát hiện các API không hoạt động, API cũ và API zombie
• Xác định các miền bóng mờ bị lãng quên, bỏ mặc hoặc không được biết đến
• Loại bỏ các điểm mù và phát hiện các đường tấn công tiềm ẩn

2. Quản lý tình trạng bảo mật API

Khi đã có danh sách đầy đủ các API, điều quan trọng là phải hiểu loại dữ liệu nào đang được truyền qua API và cách nó ảnh hưởng đến khả năng tuân thủ quy định của bạn. Quản lý tình trạng bảo mật API cung cấp cái nhìn tổng thể về lưu lượng, mã nguồn và cấu hình để đánh giá mức độ an toàn của API trong tổ chức.

Các khả năng cốt lõi cần có:

• Tự động quét hạ tầng để phát hiện lỗi cấu hình và rủi ro tiềm ẩn
• Tạo quy trình làm việc tùy chỉnh để thông báo cho các bên liên quan về lỗ hổng bảo mật
• Xác định API và người dùng nội bộ có quyền truy cập vào dữ liệu nhạy cảm
• Gán mức độ nghiêm trọng cho các vấn đề được phát hiện để ưu tiên khắc phục

3. Bảo mật API trong quá trình hoạt động

Bạn chắc hẳn đã quen với khái niệm “giả định bị xâm phạm.” Các cuộc tấn công và vi phạm liên quan đến API cũng đang trở nên phổ biến với mức độ tương tự. Đối với tất cả các API đang hoạt động, bạn cần khả năng phát hiện và chặn các cuộc tấn công theo thời gian thực.

Những khả năng cốt lõi cần có:

• Giám sát các dấu hiệu chỉnh sửa dữ liệu, rò rỉ thông tin, vi phạm chính sách, hành vi đáng ngờ và các cuộc tấn công API.
• Phân tích lưu lượng API mà không cần thay đổi mạng hoặc cài đặt các tác nhân phức tạp.
• Tích hợp với các hệ thống hiện có (quản lý vé, SIEM, v.v.) để cảnh báo cho đội ngũ bảo mật và vận hành.
• Ngăn chặn các cuộc tấn công và hành vi lạm dụng ngay lập tức bằng các biện pháp khắc phục tự động một phần hoặc hoàn toàn.

4. Kiểm tra bảo mật API

Các nhóm phát triển API chịu áp lực phải làm việc nhanh chóng nhất có thể. Tốc độ là yếu tố quan trọng trong mọi ứng dụng được phát triển, điều này có thể khiến lỗ hổng hoặc lỗi thiết kế xảy ra và không được phát hiện kịp thời. Kiểm tra API trong giai đoạn phát triển trước khi đưa vào sản xuất giúp giảm đáng kể rủi ro và chi phí khắc phục các API dễ bị tấn công.

Những khả năng cốt lõi cần có:

• Chạy nhiều bài kiểm tra tự động mô phỏng lưu lượng độc hại
• Phát hiện lỗ hổng trước khi API đi vào sản xuất, giảm nguy cơ bị tấn công thành công
• Kiểm tra các đặc tả API theo các chính sách và quy tắc quản trị đã thiết lập
• Thực hiện các bài kiểm tra bảo mật API theo yêu cầu hoặc tích hợp vào quy trình CI/CD

Cách Akamai API Security có thể đơn giản hóa sự phức tạp trong tuân thủ API

APIs là một trong những nguyên nhân hàng đầu gây ra các vi phạm bảo mật mà các quy định hiện nay đang cố gắng ngăn chặn. Vậy cần làm gì để bảo vệ doanh nghiệp khi số lượng API và rủi ro ngày càng gia tăng? Các công cụ bảo vệ API cơ bản mà nhiều tổ chức đang sử dụng có thể cung cấp một mức độ bảo vệ nhất định, nhưng vẫn chưa đủ. Nếu bạn đang tìm kiếm một giải pháp tốt hơn để bảo vệ API của doanh nghiệp và đảm bảo tuân thủ quy định, chúng tôi sẵn sàng hỗ trợ bạn.

Với mọi yêu cầu và hướng dẫn được đề cập trong tài liệu này, Akamai API Security giúp tăng cường bảo vệ mà doanh nghiệp cần—không chỉ để tuân thủ quy định mà còn để bảo vệ dữ liệu và niềm tin của khách hàng.

Giải pháp toàn diện của Akamai bảo vệ API từ giai đoạn đầu phát triển cho đến sau khi triển khai, giúp bạn tuân thủ các phương pháp bảo mật cốt lõi:

• Phát hiện API
• Quản lý tư thế bảo mật
• Bảo vệ khi chạy
• Kiểm tra bảo mật

Nguồn: API Security & Compliance: Implicit and explicit requirements for data protection

Xem thêm về các giải pháp của Akamai