Yêu cầu đối với bảo mật dữ liệu

Chuẩn bị trả lời câu hỏi bảo mật dữ liệu

Luồng dữ liệu

Tạo (hoặc cập nhật, nếu cần) phần mô tả hoặc sơ đồ luồng dữ liệu trình bày cách ứng dụng hoặc hệ thống xử lý Dữ liệu nền tảng.

1. Phía máy khách - Bao gồm tất cả phần mềm trên máy khách, chẳng hạn như trình duyệt, thiết bị di động và mọi loại thiết bị khác được hỗ trợ.
2. Phía máy chủ - Bao gồm mọi môi trường đám mây hoặc máy chủ liên quan và xác định:
1. Các thành phần mà ở đó Dữ liệu nền tảng:
1. Vào hoặc thoát khỏi (các) môi trường máy chủ (ví dụ: trình nghe web và API REST)
2. Được ghi vào bộ nhớ cố định hoặc bền bỉ, chẳng hạn như cơ sở dữ liệu, đĩa hoặc file nhật ký
2. Mô hình lưu trữ, ví dụ:
1. Tự lưu trữ - máy chủ riêng của tổ chức chạy trong trung tâm dữ liệu được sở hữu hoặc chia sẻ.
2. Cơ sở hạ tầng dưới dạng dịch vụ (IaaS) - chẳng hạn như AWS EC2, Microsoft Azure IaaS và Google Compute Engine.
3. Nền tảng dưới dạng dịch vụ (PaaS) - chẳng hạn như AWS Elastic Beanstalk, Google App Engine, Force.com.
4. Sản phẩm phụ trợ dưới dạng dịch vụ (BaaS) - chẳng hạn như AWS Amplify, Azure Mobile Apps, Firebase và MongoDB Switch.
5. Kết hợp - một số kiểu kết hợp các mô hình nêu trên.

Cuối cùng, phần mô tả hoặc sơ đồ luồng dữ liệu phải bao gồm:

1. Nơi tạo và truyền tải/lưu trữ/gia hạn mã truy cập API của Meta, trong cả phần mềm máy khách và máy chủ (nếu áp dụng cho thiết kế hệ thống)
2. Cách bạn tìm nạp Dữ liệu nền tảng từ API của Meta, tập trung cụ thể vào Thông tin nhận dạng cá nhân (PII) như tên, địa chỉ email, giới tính, ngày sinh của cá nhân và dữ liệu khác của người dùng
3. Cách bạn sử dụng, lưu trữ và truyền tải dữ liệu này
4. Bất kỳ bên thứ 4 nào tiếp nhận Dữ liệu nền tảng

Chuẩn bị bằng chứng

Bạn có thể phải gửi bằng chứng để hỗ trợ câu trả lời liên quan đến biện pháp bảo mật dữ liệu mà bạn triển khai. Bạn nên đọc Hướng dẫn về bằng chứng trong tài liệu này để biết ví dụ về bằng chứng được chấp nhận và chuẩn bị bằng chứng theo đó. Chúng tôi chấp nhận các loại tệp tài liệu phổ biến cùng với ảnh chụp màn hình và bản ghi màn hình. Vui lòng đảm bảo các tệp không được bảo vệ bằng mật khẩu. Bạn có thể tải nhiều tệp lên, mỗi tệp có kích thước tối đa là 2 GB. Chúng tôi chấp nhận các định dạng .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip và .zipx.

Các loại bằng chứng

Đối với ứng dụng được yêu cầu tải lên bằng chứng liên quan đến biện pháp bảo mật dữ liệu, Meta yêu cầu 2 loại tài liệu khác nhau:

1. Bằng chứng về chính sách hoặc quy trình – Tài liệu về chính sách hoặc quy trình giải thích cách tiến hành biện pháp bảo mật dữ liệu cho [biện pháp bảo vệ này]
2. Bằng chứng triển khai – Bằng chứng từ hệ thống hoặc ứng dụng, chẳng hạn như cấu hình công cụ hay ảnh chụp màn hình, cho biết cách bạn triển khai một biện pháp bảo vệ cụ thể

Bằng chứng về chính sách hoặc quy trình

Bằng chứng về chính sách hoặc quy trình (đôi khi còn gọi là biện pháp kiểm soát quản trị) là văn bản tài liệu mô tả cách tiến hành một biện pháp bảo mật dữ liệu cụ thể. Bằng chứng này có thể tồn tại dưới nhiều dạng. Đó có thể là đoạn trích từ một bộ chính sách nội bộ, một phần hay toàn bộ trang wiki nội bộ hoặc một tài liệu mới tạo mà bạn sử dụng để mô tả cách tiến hành biện pháp nếu không có sẵn tài liệu. Trong trường hợp bất kỳ, bằng chứng về chính sách hoặc quy trình mà bạn tải lên phải giải thích rõ ràng mức độ liên quan của cách tiến hành biện pháp bảo vệ dữ liệu cụ thể với các yêu cầu của Meta. Vui lòng chỉ cung cấp chính sách hoặc ngôn ngữ có liên quan và cần thiết để Meta đánh giá tính bảo mật. Bạn cũng có thể sử dụng hộp không có văn bản đi kèm với câu hỏi để chuyển hướng người đánh giá đến (các) phần phù hợp.

Bằng chứng triển khai

Bằng chứng triển khai cho biết cách bạn triển khai trên thực tế chính sách hoặc quy trình một cách trực tiếp qua ảnh chụp màn hình/bản ghi màn hình. Do mỗi nhà phát triển lại có cấu hình khác nhau nên chúng tôi không thể cung cấp ví dụ cho từng trường hợp. Dù vậy, bằng chứng triển khai cần thể hiện cùng một mức độ chi tiết nhất có thể như ví dụ mà chúng tôi cung cấp.

Tính đầy đủ của bằng chứng

Chúng tôi hiểu rằng việc chuẩn bị bằng chứng triển khai (cho thấy toàn diện hoạt động triển khai biện pháp bảo mật dữ liệu cụ thể) có thể là gánh nặng không cần thiết. Do đó, bạn nên gửi bằng chứng theo hướng dẫn ở đây, nhớ loại bỏ thông tin nhạy cảm khỏi bằng chứng trước khi gửi:

1. Bằng chứng về chính sách hoặc quy trình phải đáp ứng hoặc vượt mức các yêu cầu của Meta một cách rõ ràng
1. Meta sẽ xem xét bằng chứng về chính sách hoặc quy trình để đưa ra nhận định phù hợp với các yêu cầu của Meta cho biện pháp bảo vệ cụ thể.
2. Bạn nên chú thích tài liệu để nêu bật các phần có liên quan
3. Ví dụ: liên quan đến biện pháp bảo vệ Triển khai phương thức mã hóa TLS 1.2 trở lên cho tất cả các kết nối mạng có hoạt động truyền Dữ liệu trên nền tảng, chúng tôi chấp nhận bằng chứng chứa tài liệu nêu rõ:
1. Tuyệt đối không truyền Dữ liệu trên nền tảng của Meta qua các mạng không đáng tin cậy ở định dạng không được mã hóa
2. Tất cả các trình nghe trên web (ví dụ: trình cân bằng tải truy cập từ Internet) tiếp nhận hoặc trả lại Dữ liệu trên nền tảng sẽ được đặt cấu hình sao cho có thể triển khai TLS 1.2
3. Tất cả các trình nghe trên web tiếp nhận hoặc trả lại Dữ liệu trên nền tảng sẽ được đặt cấu hình sao cho các giao thức sau đây bị vô hiệu hóa: SSL v2, SSL v3, TLS 1.0 và TLS 1.1
2. Bằng chứng triển khai phải cho thấy một hoặc nhiều ví dụ về từng hoạt động triển khai chính sách/quy trình
1. Bạn phải tải lên một hoặc nhiều tài liệu, ảnh chụp màn hình hay cấu hình công cụ cho thấy cách bạn triển khai từng biện pháp bảo vệ
2. Meta sẽ xem xét bằng chứng triển khai để đảm bảo bằng chứng này phù hợp với bằng chứng về chính sách hoặc quy trình
3. Ví dụ: liên quan đến biện pháp bảo vệ Triển khai phương thức mã hóa TLS 1.2 trở lên cho tất cả các kết nối mạng có hoạt động truyền Dữ liệu trên nền tảng, chúng tôi chấp nhận bằng chứng chứa báo cáo kiểm tra Qualys SSL cho một trong những miền web được đặt cấu hình theo chính sách hoặc quy trình.

Dữ liệu nhạy cảm bạn cần loại bỏ khỏi bằng chứng

Không gửi bằng chứng chứa một trong các giá trị sau ở dạng đọc được (không loại bỏ). Nếu bạn đang dùng trình chỉnh sửa hình ảnh cho ảnh chụp màn hình, hãy đặt một hộp đen lên trên giá trị đó. Nếu bạn dùng trình chỉnh sửa PDF, hãy nhớ loại bỏ văn bản bằng cách dùng công cụ mà thực sự gỡ giá trị chứ không chỉ đơn thuần là thêm một lớp trong khi giữ nguyên văn bản (ví dụ: công cụ loại bỏ trong ứng dụng Xem trước của Apple).

• Dữ liệu sức khỏe
• Dữ liệu tài chính
• Địa chỉ IP
• Mật khẩu, thông tin đăng nhập và mã truy cập
• Khóa mã hóa
• Địa chỉ thực
• Thông tin nhận dạng cá nhân (PII) về một thực nhân (không bao gồm doanh nghiệp hoặc các tổ chức doanh nghiệp khác), nhân viên hay các công ty liên kết có thể nhận dạng cá nhân đó trực tiếp/gián tiếp, chẳng hạn như:

  • Tên
  • Địa chỉ email
  • ID người dùng
  • Ngày sinh
  • Dữ liệu vị trí
  • Dữ liệu sức khỏe
  • Thông tin nhận dạng liên quan đến văn hóa, xã hội, chính trị
  • Dữ liệu có thể nhận dạng cá nhân theo cách khác trong ngữ cảnh cụ thể của bằng chứng
• Các bước tái hiện chi tiết cho lỗ hổng bảo mật (ví dụ: trong báo cáo kiểm tra mức độ xâm nhập)
• Dữ liệu của hoặc về trẻ em dưới 13 tuổi mà nhà phát triển biết hoặc nên biết một cách hợp lý

Dùng tính năng mã hóa ở trạng thái nghỉ để bảo vệ Dữ liệu trên nền tảng được lưu trữ tại phía máy chủ

Câu hỏi: Bạn có áp dụng tính năng mã hóa ở trạng thái nghỉ cho tất cả Dữ liệu trên nền tảng được lưu trữ trong môi trường trung tâm dữ liệu, máy chủ hoặc đám mây không?

Ý định

Tính năng mã hóa ở trạng thái nghỉ bảo vệ Dữ liệu trên nền tảng bằng cách chuyển dữ liệu thành định dạng không đọc được nếu không có khóa giải mã riêng biệt, nhờ đó bổ sung một lớp bảo vệ nhằm ngăn quyền đọc trái phép.

• Trên máy chủ hoặc trong môi trường đám mây – nơi thường tập trung Dữ liệu trên nền tảng liên quan đến tất cả người dùng ứng dụng, tính năng mã hóa ở trạng thái nghỉ sẽ hạn chế nguy cơ dữ liệu bị xâm phạm
• Ví dụ: tính năng mã hóa ở trạng thái nghỉ ngăn ngừa các mối đe dọa như hành vi truy cập trái phép vào bản sao lưu cơ sở dữ liệu. Đây là thông tin có thể không được bảo vệ kỹ càng như chính cơ sở dữ liệu sản xuất

Tóm tắt các yêu cầu

Nếu lưu trữ Dữ liệu trên nền tảng tại phía máy chủ:

• Bạn PHẢI bảo vệ dữ liệu đó:

  • Bằng tính năng mã hóa ở trạng thái nghỉ hoặc
  • Bằng biện pháp bảo vệ khác được chấp nhận (xem Biện pháp bảo vệ khác được chấp nhận)

• Bạn cần xác định cụ thể phương thức mã hóa mình dùng:

  • Có thể mã hóa ở cấp độ ứng dụng (ví dụ: phần mềm mã hóa/giải mã các cột cụ thể trong cơ sở dữ liệu) hoặc toàn bộ ổ đĩa
  • Mặc dù thấy rằng bạn nên dùng phương thức mã hóa tiêu chuẩn của ngành (ví dụ: AES, BitLocker, Blowfish, TDES, RSA), nhưng chúng tôi không đặt ra yêu cầu cụ thể nào về thuật toán hay độ dài khóa

Nếu nhà phát triển KHÔNG lưu trữ Dữ liệu trên nền tảng tại phía máy chủ, yêu cầu này sẽ không áp dụng.

Trường hợp đặc biệt

Phương pháp Lưu trữ tại phía máy chủ dùng các hình thức Lưu trữ qua IaaS, Tự lưu trữ hoặc Lưu trữ kết hợp

Nếu lưu trữ Dữ liệu trên nền tảng bằng hình thức lưu trữ qua IaaS (ví dụ: AWS EC2, Microsoft Azure IaaS và Google Compute Engine), tự lưu trữ hay lưu trữ kết hợp, bạn cần trả lời câu hỏi này.

Phương pháp Lưu trữ tại phía máy chủ bằng các sản phẩm SaaS, PaaS hoặc BaaS

Tuy nhiên, có những mô hình lưu trữ phụ trợ khác là trường hợp đặc biệt:

Nếu chỉ lưu trữ Dữ liệu trên nền tảng qua một sản phẩm bất kỳ nêu trên (và không dùng hình thức Lưu trữ qua IaaS, Tự lưu trữ hoặc Lưu trữ kết hợp), bạn không cần trả lời câu hỏi này. Thay vào đó, bạn nên mô tả mối quan hệ này trong phần Nhà cung cấp dịch vụ của bản Đánh giá việc bảo vệ dữ liệu.

• BaaS – ví dụ: AWS Amplify, Azure Mobile Apps, Azure Playfab, Google Firebase và MongoDB Switch
• PaaS – ví dụ: AWS Elastic Beanstalk, Google App Engine, Force.com
• SaaS – ví dụ: MailChimp hoặc Salesforce

Phương pháp Lưu trữ tại phía máy chủ bằng API của Meta

Nếu bạn chỉ lưu trữ Dữ liệu trên nền tảng qua API của Meta (chẳng hạn như bằng player.setDataAsync()) trong SDK Trò chơi tức thì, bạn không cần trả lời câu hỏi này.

Hướng dẫn về bằng chứng

Nếu bạn được yêu cầu gửi bằng chứng về biện pháp bảo vệ này, hãy làm theo hướng dẫn trong phần Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai.

Ví dụ về bằng chứng triển khai

AWS RDS

AWS RDS – nhà phát triển có thể đặt cấu hình tính năng mã hóa ở trạng thái nghỉ trong AWS RDS, do đó họ phải đảm bảo đã thiết lập lựa chọn cấu hình để áp dụng biện pháp bảo vệ này.

Đối với phiên bản RDS đại diện có chứa Dữ liệu trên nền tảng, hãy dùng công cụ AWS CLI để tìm nạp cấu hình StorageEncrypted tương ứng.

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

Theo mặc định, AWS DynamoDB được mã hóa ở trạng thái nghỉ. Bạn có thể tìm nạp cấu hình tính năng mã hóa ở trạng thái nghỉ cho bảng bằng những lệnh này.

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

AWS DocumentDB phải được đặt cấu hình để áp dụng tính năng mã hóa ở trạng thái nghỉ. Đối với cụm đại diện có chứa Dữ liệu trên nền tảng, hãy dùng những lệnh này để tìm nạp cấu hình StorageEncrypted.

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

Nhóm AWS S3 có thể được đặt cấu hình để áp dụng tính năng mã hóa ở trạng thái nghỉ cho tất cả đối tượng đã tạo trong nhóm đó. Hãy dùng những lệnh này để liệt kê các nhóm và tìm nạp cấu hình cho phương thức mã hóa nhóm mặc định.

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

Hãy tham khảo tài liệu của Microsoft về tính năng mã hóa ở trạng thái nghỉ trong Azure có liên quan đến việc tổ chức dùng dịch vụ của Microsoft.

Google Cloud Platform

Hãy tham khảo tài liệu của Google về tính năng mã hóa ở trạng thái nghỉ trên Google Cloud Platform.

Biện pháp bảo vệ khác được chấp nhận

Nếu không triển khai tính năng mã hóa ở trạng thái nghỉ trong môi trường phía máy chủ, có thể bạn đang bảo vệ Dữ liệu trên nền tảng bằng cách khác vẫn được chấp nhận. Trong trường hợp này, bạn nên mô tả những nội dung sau đây:

1. Tính nhạy cảm của Dữ liệu trên nền tảng – Bộ nhớ Dữ liệu cụ thể trên nền tảng được cho là có rủi ro thấp hơn hay cao hơn. Bạn sẽ cần nghiên cứu xem các thuộc tính cụ thể nào của người dùng Dữ liệu trên nền tảng đang được lưu trữ tại phía máy chủ.
2. Biện pháp kiểm soát giảm khả năng xảy ra tổn hại cụ thể
1. Biện pháp kiểm soát ngăn ngừa hành vi xâm phạm những mạng có chứa Dữ liệu trên nền tảng
2. Biện pháp kiểm soát ngăn ngừa hành vi xâm phạm những ứng dụng/hệ thống có quyền truy cập vào Dữ liệu trên nền tảng
3. Biện pháp kiểm soát ngăn ngừa tổn thất về phương tiện lưu trữ vật lý (ví dụ: thiết bị lưu trữ qua mạng ngừng hoạt động) có chứa Dữ liệu trên nền tảng
4. Biện pháp kiểm soát ngăn ngừa tổn thất về phương tiện lưu trữ vật lý (ví dụ: thiết bị lưu trữ qua mạng ngừng hoạt động) có chứa Dữ liệu trên nền tảng
5. Biện pháp kiểm soát ngăn ngừa hành vi truy cập trái phép vào bản sao lưu bộ nhớ có chứa Dữ liệu trên nền tảng
3. Sức thuyết phục của bằng chứng – hãy nêu rõ nếu một bên đánh giá độc lập đã đánh giá các biện pháp bảo vệ này, chẳng hạn như thông qua cuộc đánh giá SOC2.

Bảo vệ để không làm mất Dữ liệu trên nền tảng được lưu trữ trong các thiết bị của tổ chức và phương tiện lưu trữ di động

Câu hỏi: Cụ thể liên quan đến dữ liệu được lưu trữ trong các thiết bị của cá nhân và tổ chức: Bạn có thực thi phương thức mã hóa ở trạng thái nghỉ hay áp dụng các chính sách và quy tắc để giảm nguy cơ mất dữ liệu đối với tất cả Dữ liệu trên nền tảng được lưu trữ trong những thiết bị này hay không?

Ý định

Nếu nhà phát triển cho phép lưu trữ Dữ liệu trên nền tảng trong những thiết bị như máy tính xách tay của nhân viên hay phương tiện lưu trữ di động (ví dụ: ổ đĩa USB), dữ liệu đó có nguy cơ cao bị truy cập trái phép trong trường hợp thiết bị đã mất hoặc bị đánh cắp. Nhà phát triển phải thực hiện các bước để hạn chế rủi ro này.

Tóm tắt các yêu cầu

• Để giảm nguy cơ Dữ liệu trên nền tảng bị truy cập trái phép, Nhà phát triển phải có các biện pháp kiểm soát về mặt kỹ thuật (ưu tiên) hoặc hành chính (không ưu tiên nhưng chấp nhận được) liên quan đến Dữ liệu trên nền tảng được lưu trữ trong các thiết bị của tổ chức (ví dụ: máy tính xách tay) và phương tiện lưu trữ di động.

  • Biện pháp kiểm soát về mặt kỹ thuật – đây là các ví dụ minh họa biện pháp kiểm soát về mặt kỹ thuật: 1) Chỉ cho phép các thiết bị được quản lý kết nối với mạng công ty, 2) thực thi phương thức mã hóa toàn bộ ổ đĩa trên các thiết bị được quản lý (ví dụ: BitLocker), 3) Chặn không cho phương tiện lưu trữ di động (ví dụ: ổ đĩa USB) kết nối với các thiết bị được quản lý, 4) sử dụng công nghệ Ngăn chặn mất dữ liệu (DLP) trên các thiết bị được quản lý.
  • Biện pháp kiểm soát về mặt hành chính – đây là các ví dụ minh họa biện pháp kiểm soát về mặt hành chính: tài liệu chính sách dạng văn bản và khóa đào tạo hàng năm về những cách được chấp nhận để xử lý Dữ liệu trên nền tảng trong các thiết bị của cá nhân và tổ chức.

Hướng dẫn về bằng chứng

Nếu bạn được yêu cầu gửi bằng chứng về biện pháp bảo vệ này, hãy làm theo hướng dẫn trong phần Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai.

Bạn có thể sử dụng một hoặc cả hai: a) biện pháp kiểm soát về mặt kỹ thuật (ví dụ: mã hóa ổ đĩa) hoặc b) quy tắc/chính sách để giảm nguy cơ mất dữ liệu đối với Dữ liệu trên nền tảng được lưu trữ trong các thiết bị của tổ chức như máy tính xách tay và điện thoại di động.

Biện pháp kiểm soát về mặt kỹ thuật có thể bao gồm:

• Chặn không cho các thiết bị không được quản lý kết nối với những dịch vụ nhạy cảm như mạng sản xuất
• Thực thi phương thức mã hóa ổ đĩa trên các thiết bị được quản lý (ví dụ: thông qua BitLocker trên Windows hoặc FileVault trên máy Mac)
• Chặn không cho sử dụng phương tiện lưu trữ di động (ví dụ: ổ đĩa USB) trên các thiết bị được quản lý
• Sử dụng phần mềm DLP trên các thiết bị được quản lý để chặn hoạt động xử lý Dữ liệu trên nền tảng không đúng cách (ví dụ: gửi dữ liệu đó trong một tệp đính kèm email)

Quy tắc/chính sách có thể bao gồm:

• Tài liệu mô tả những cách được chấp nhận và không được chấp nhận khi xử lý dữ liệu nói chung và Dữ liệu trên nền tảng nói riêng
• Cơ chế giúp các thành viên trong tổ chức nắm rõ nguyên tắc (ví dụ: thỏa thuận theo hợp đồng là điều kiện làm việc, khóa đào tạo, lời nhắc định kỳ qua email)

Bằng chứng mẫu

Một tổ chức phân loại Dữ liệu trên nền tảng của Meta là "dữ liệu riêng tư" theo tiêu chuẩn phân loại dữ liệu của họ. Tổ chức này đã xây dựng Nguyên tắc xử lý dữ liệu, đồng thời yêu cầu tất cả nhân viên phải nắm rõ và tuân thủ các chính sách này.

Bảo vệ Dữ liệu trên nền tảng được truyền qua các mạng áp dụng phương thức mã hóa khi truyền

Câu hỏi: Bạn có triển khai giao thức bảo mật TLS 1.2 trở lên cho mọi kết nối mạng chuyển qua hoặc kết nối hay đi qua các mạng công cộng mà hoạt động truyền Dữ liệu trên nền tảng xảy ra hay không? Ngoài ra, bạn có đảm bảo tuyệt đối không truyền Dữ liệu trên nền tảng ở dạng chưa mã hóa qua mạng công cộng (ví dụ: qua HTTP hoặc FTP), cũng như không sử dụng giao thức bảo mật SSL v2 và SSL v3 không?

Ý định

Bất kỳ ai có thể quan sát lưu lượng truy cập mạng đều có khả năng tiếp cận Dữ liệu trên nền tảng được truyền qua Internet. Do đó, dữ liệu này phải được bảo vệ bằng phương thức mã hóa để ngăn các bên trái phép đọc được dữ liệu.

• Phương thức mã hóa khi truyền bảo vệ Dữ liệu trên nền tảng khi dữ liệu được truyền qua các mạng không đáng tin cậy (ví dụ: mạng Internet) bằng cách chuyển dữ liệu thành dạng không đọc được nếu không phải là thiết bị gửi và nhận
• Nói cách khác, các bên ở giữa quá trình truyền sẽ không thể đọc được Dữ liệu trên nền tảng ngay cả khi họ có thể nhìn thấy lưu lượng truy cập mạng (đây còn gọi là cuộc tấn công xen giữa (man-in-the-middle))
• TLS là hình thức mã hóa phổ biến nhất khi truyền vì đó là công nghệ mà các trình duyệt sử dụng để bảo mật thông tin liên lạc đến các trang web như ngân hàng

Tóm tắt các yêu cầu

Dù bạn có xử lý Dữ liệu trên nền tảng tại phía máy chủ hay không:

• Tuyệt đối không truyền Dữ liệu trên nền tảng qua các mạng không đáng tin cậy ở định dạng không được mã hóa
• Đối với tất cả trình nghe trên web (ví dụ: trình cân bằng tải truy cập từ Internet) tiếp nhận hoặc trả về Dữ liệu trên nền tảng, bạn phải:

  • Triển khai TLS 1.2 trở lên
  • Vô hiệu hóa SSL v2 và SSL v3
• Chỉ sử dụng TLS 1.0 và TLS 1.1 để đảm bảo tương thích với các thiết bị khách không hỗ trợ TLS 1.2 trở lên
• Meta khuyến nghị (nhưng không yêu cầu) áp dụng phương thức mã hóa khi truyền cho hoạt động truyền Dữ liệu trên nền tảng nằm hoàn toàn trong mạng riêng tư, chẳng hạn như trong Đám mây riêng ảo (VPC).

Dưới đây là bảng tóm tắt chính sách về phương thức mã hóa khi truyền cho các hình thức truyền dữ liệu khác nhau.

Hướng dẫn về bằng chứng

Nếu bạn được yêu cầu gửi bằng chứng về biện pháp bảo vệ này, hãy làm theo hướng dẫn trong mục Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai. Một cách đơn giản để tạo bằng chứng triển khai minh họa cấu hình của một trong các trình nghe trên web là sử dụng công cụ Qualys SSL Server Test.

• Chạy công cụ Qualys SSL Server Test cho 1 hoặc nhiều trình nghe trên web có cấu hình giống hệt nhau (bao gồm bất kỳ trình nghe nào chạy trên các cổng không tiêu chuẩn).
• Chọn "Không hiển thị kết quả trên bảng" để không thêm kết quả vào trang web Qualys. In toàn bộ trang kết quả kiểm tra dưới dạng PDF. Lặp lại các bước nêu trên cho bất kỳ trình nghe trên web nào có cấu hình TLS khác mà Dữ liệu trên nền tảng được truyền đến/từ đó

Ví dụ về bằng chứng triển khai

Đây là ví dụ về kết quả thu được từ công cụ Qualys SSL Server Test. Các chú thích màu đỏ trong phần Cấu hình tóm tắt phiên bản SSL/TLS được hỗ trợ. Lưu ý: ví dụ này chỉ có 2 trang đầu tiên nhưng bạn cần gửi toàn bộ kết quả kiểm tra.

Biện pháp bảo vệ khác được chấp nhận

Ngoài TLS, bạn có thể bảo vệ Dữ liệu trên nền tảng bằng phương thức mã hóa khi truyền khác, miễn là phương thức đó có khả năng bảo vệ tương đương. Trong trường hợp này, bạn cần gửi thông tin chi tiết về phương thức mã hóa mình dùng để Meta xem xét:

• Phương thức mã hóa đó đối xứng hay không đối xứng?
• Thuật toán mã hóa (ví dụ: AES, BitLocker, TDES, RSA) là gì?
• Độ dài tối thiểu của khóa là bao nhiêu?

Kiểm tra ứng dụng và hệ thống để phát hiện lỗ hổng và sự cố bảo mật

Câu hỏi: Bạn có kiểm tra ứng dụng và hệ thống để phát hiện lỗ hổng và sự cố bảo mật ít nhất 1 lần/năm không? (Ví dụ: bạn có tiến hành kiểm thử thâm nhập theo cách thủ công không?)

Ý định

Nhà phát triển phải kiểm tra lỗ hổng và sự cố bảo mật để chủ động phát hiện chúng, tốt nhất là ngăn chặn các sự cố bảo mật trước khi chúng xảy ra

• Nhà phát triển ứng dụng dùng nền tảng của Meta để xử lý Dữ liệu trên nền tảng bằng phần mềm mà họ viết thông qua các ứng dụng/hệ thống mà họ đặt cấu hình và vận hành
• Cấu hình phần mềm và hệ thống có thể chứa lỗ hổng bảo mật mà các tác nhân độc hại có thể khai thác, dẫn đến việc truy cập trái phép vào Dữ liệu trên nền tảng

Tóm tắt các yêu cầu

Áp dụng cho tất cả nhà phát triển:

• Bạn phải kiểm tra phần mềm được sử dụng để xử lý Dữ liệu trên nền tảng nhằm phát hiện lỗ hổng bảo mật bằng cách tiến hành:

  • Kiểm thử thâm nhập ứng dụng/hệ thống, hoặc
  • Quét lỗ hổng bảo mật/phân tích tĩnh phần mềm
• Kết quả kiểm tra phải cho thấy không có lỗ hổng rất nghiêm trọng hoặc cực nghiêm trọng nào chưa được khắc phục
• Thời điểm bạn hoàn tất quy trình kiểm tra này phải trong vòng 12 tháng qua

Yêu cầu bổ sung đối với nhà phát triển xử lý Dữ liệu trên nền tảng tại phía máy chủ:

• Bạn phải kiểm tra cụ thể phần mềm phía máy chủ nhằm phát hiện lỗ hổng bảo mật bằng cách tiến hành:

  • Kiểm thử thâm nhập ứng dụng/hệ thống, hoặc
  • Quét lỗ hổng bảo mật/phân tích tĩnh Nếu đang sử dụng nhà cung cấp dịch vụ lưu trữ đám mây, bạn cũng phải kiểm tra cấu hình đám mây nhằm phát hiện sự cố bảo mật Yêu cầu này được áp dụng bất kể bạn sử dụng phương pháp lưu trữ nào (ví dụ: BaaS, PaaS, IaaS, tự lưu trữ hay kết hợp)

Hướng dẫn về bằng chứng

Nếu bạn được yêu cầu gửi bằng chứng về biện pháp bảo vệ này, hãy làm theo hướng dẫn trong mục Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai.

Nếu tổ chức xử lý Dữ liệu trên nền tảng trong môi trường đám mây/máy chủ:

• Gửi bằng chứng cho thấy bạn đã hoàn tất quy trình kiểm thử thâm nhập hoặc triển khai công cụ SAST. Bằng chứng phải bao gồm:

  • Phần trình bày phạm vi kiểm tra
  • Ngày hoàn tất quy trình kiểm tra – ngày này phải trong vòng 12 tháng qua
  • Bản tóm tắt hoặc danh sách các lỗ hổng bảo mật phát hiện được trong quá trình kiểm tra. Bản tóm tắt hoặc danh sách này phải phân loại mức độ nghiêm trọng (ví dụ: cực nghiêm trọng, rất nghiêm trọng, nghiêm trọng vừa phải, không quá nghiêm trọng, mang tính cung cấp thông tin). Thông thường, chúng tôi mong rằng không có lỗ hổng rất nghiêm trọng hoặc cực nghiêm trọng nào chưa được khắc phục

• Nếu áp dụng (tức là nếu bạn đang sử dụng dịch vụ lưu trữ đám mây như AWS, GCP, Azure hoặc tương tự), hãy gửi bằng chứng cho thấy bạn đã thực hiện quy trình đánh giá cấu hình đám mây. Ví dụ: kết quả chạy NCC Scout Suite, AWS Config hoặc tương tự. Nếu trường hợp này không áp dụng cho tổ chức, hãy thêm tài liệu giải thích lý do không cần thực hiện quy trình đánh giá cấu hình đám mây vào nội dung gửi bằng chứng.
• Gỡ hoặc loại bỏ thông tin nhạy cảm (chẳng hạn như chi tiết về các bước tái tạo lỗ hổng bảo mật) khỏi bằng chứng trước khi gửi

Nếu tổ chức KHÔNG xử lý Dữ liệu trên nền tảng trong môi trường đám mây/máy chủ:

• Gửi bằng chứng cho thấy bạn đã hoàn tất quy trình kiểm thử thâm nhập hoặc triển khai công cụ SAST. Bằng chứng phải bao gồm:

  • Phần trình bày phạm vi kiểm tra
  • Ngày hoàn tất quy trình kiểm tra – ngày này phải trong vòng 12 tháng qua
  • Bản tóm tắt hoặc danh sách các lỗ hổng bảo mật phát hiện được trong quá trình kiểm tra. Bản tóm tắt hoặc danh sách này phải phân loại mức độ nghiêm trọng (ví dụ: cực nghiêm trọng, rất nghiêm trọng, nghiêm trọng vừa phải, không quá nghiêm trọng, mang tính cung cấp thông tin). Thông thường, chúng tôi mong rằng không có lỗ hổng rất nghiêm trọng hoặc cực nghiêm trọng nào chưa được khắc phục.
• Gỡ hoặc loại bỏ thông tin nhạy cảm (chẳng hạn như chi tiết về các bước tái tạo lỗ hổng bảo mật) khỏi bằng chứng trước khi gửi

Bằng chứng mẫu

Kiểm thử thâm nhập – Một tổ chức ủy thác cho công ty khác kiểm thử thâm nhập phần mềm mà họ sở hữu. Phần mềm này chạy tại phía máy chủ tích hợp với các API của Meta và xử lý Dữ liệu trên nền tảng. Công ty kiểm tra hoàn tất quy trình kiểm tra và đưa ra bản tóm tắt như bên dưới. Hãy lưu ý đến các chú thích màu đỏ nêu bật ngày tiến hành kiểm tra (phải trong vòng 12 tháng qua) và thông tin tóm tắt những phát hiện cực/rất nghiêm trọng chưa được khắc phục ở phần kết luận quy trình kiểm tra (hoặc kiểm tra lại, nếu có). Vui lòng loại bỏ thông tin nhạy cảm khỏi báo cáo (cụ thể là mọi chi tiết về các bước tái tạo lỗ hổng bảo mật) trước khi gửi.

Phân tích tĩnh – Nếu bạn sử dụng phương pháp khác (ví dụ: công cụ SAST), hãy xuất kết quả thành tài liệu. Tài liệu này phải bao gồm ngày chạy SAST và danh sách những phát hiện nêu rõ từng loại phát hiện cùng mức độ nghiêm trọng của phát hiện đó.

Đánh giá cấu hình đám mây

Nhà phát triển sử dụng NCC Scout Suite theo bộ quy tắc mặc định được áp dụng cho nhà cung cấp dịch vụ đám mây của họ (trong trường hợp này là AWS) để xem xét cấu hình đám mây nhằm phát hiện lỗ hổng và sự cố bảo mật. Công cụ trả về tệp JSON chứa kết quả kiểm tra chi tiết. Trong ví dụ này, có một số sự cố bị gắn cờ là mức độ nghiêm trọng "Nguy hiểm" mà nhà phát triển cần xem xét và khắc phục.

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

Một phương pháp khác để xem xét cấu hình đám mây dành cho những nhà phát triển sử dụng bộ quy tắc Amazon Web Services.

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

Biện pháp bảo vệ khác được chấp nhận

Nếu đang vận hành một Chương trình tiết lộ lỗ hổng bảo mật (VDP) vẫn hoạt động bình thường, chẳng hạn như nền tảng BugCrowd hoặc HackerOne, bạn có thể trình bày rằng chương trình này là biện pháp bảo vệ thay thế cho quy trình kiểm thử thâm nhập hoặc quét lỗ hổng bảo mật. Để chứng minh, bạn phải gửi bằng chứng cho thấy:

• Không có trường hợp loại trừ nào đối với phạm vi của VDP liên quan đến cách bạn xử lý Dữ liệu trên nền tảng
• Có nghiên cứu và báo cáo thực tế, liên tục về lỗ hổng bảo mật trong vòng 12 tháng qua, thường được chỉ ra bằng ít nhất 1 báo cáo lỗ hổng bảo mật hợp lệ mỗi tháng
• Những lỗ hổng bảo mật (hợp lệ) đã gửi được chỉ định điểm đánh giá mức độ nghiêm trọng, ví dụ: theo CVSS 3.1
• Những lỗ hổng bảo mật đã được khắc phục trong một khoảng thời gian hợp lý, thường dưới 90 ngày kể từ ngày gửi

Trong trường hợp này, bằng chứng phải bao gồm:

• Phần trình bày về phạm vi và mức độ tương quan của phạm vi đó với phần mềm được dùng để xử lý Dữ liệu trên nền tảng
• Và báo cáo tổng hợp những nội dung gửi về lỗ hổng bảo mật thực tế của chương trình trong 12 tháng qua. Báo cáo này phải bao gồm tên lỗ hổng bảo mật, ngày gửi, ngày khắc phục (nếu đã khắc phục) và hạng mục/điểm mức độ nghiêm trọng.

Bảo vệ khóa bí mật của ứng dụng Meta và mã truy cập API của Meta

Câu hỏi: Khóa bí mật của ứng dụng Meta và mã truy cập API của Meta có áp dụng 2 biện pháp bảo vệ sau đây không?

1. Tuyệt đối không lưu trữ trên thiết bị khách những mã truy cập API của Meta mà ai đó không phải người dùng có thể truy cập vào bên ngoài ứng dụng hiện tại.
2. Dùng kho lưu trữ dữ liệu (ví dụ: Vault của Hashicorp) với dịch vụ quản lý khóa riêng biệt (KMS) nếu các thông tin này được lưu trữ trong môi trường trung tâm dữ liệu, máy chủ hoặc đám mây.

Ý định

Khóa bí mật của ứng dụng và mã truy cập là những thông tin bảo mật cơ bản tác động đến cách API của Meta ra quyết định nên cho phép hành động nào. Nếu có được quyền truy cập vào các thông tin đăng nhập này, bên chưa được cấp phép có thể gọi API của Meta (tức là mạo danh nhà phát triển thật) và thực hiện hành động bất kỳ mà chúng tôi đã cấp quyền cho ứng dụng (ví dụ: đọc dữ liệu từ API của Meta về người dùng ứng dụng).

• Trong quá trình sử dụng Nền tảng của Meta, bạn có quyền truy cập vào các thông tin đăng nhập nhạy cảm. Cụ thể gồm:

  • Mã truy cập – Khi người dùng ủy quyền cho một ứng dụng, phần mềm sẽ nhận được thông tin đăng nhập (gọi là mã truy cập) để dùng trong các lệnh gọi API sau đó
  • Khóa bí mật của ứng dụng – Meta chia sẻ khóa bí mật của ứng dụng cho nhà phát triển với kỳ vọng rằng chỉ những bên đáng tin cậy (ví dụ: quản trị viên ứng dụng) thuộc tổ chức mới có quyền truy cập vào khóa này
• Bên chưa được cấp phép có thể dùng thông tin đăng nhập nhạy cảm mà họ đọc được để gọi API của Meta như thể họ là bạn (đôi khi, trường hợp này được xem là mạo danh mã) nhằm truy cập trái phép vào Dữ liệu trên nền tảng
• Do đó, bạn phải bảo vệ những thông tin đăng nhập này khỏi hành vi truy cập trái phép để tránh tình trạng bị mạo danh

Tóm tắt các yêu cầu

Mã truy cập

1. Trên thiết bị khách – Không được viết mã truy cập của Meta theo cách mà người dùng hoặc quy trình khác có thể đọc.
2. Phía máy chủ – Nếu bạn xử lý hoặc lưu trữ mã truy cập của Meta tại phía máy chủ, những mã truy cập đó:
1. Phải được bảo vệ bằng kho lưu trữ dữ liệu (ví dụ: Vault của Hashicorp) với dịch vụ quản lý khóa riêng biệt (KMS) và ở nơi mà chỉ ứng dụng mới có quyền truy cập vào khóa giải mã
2. Phải được viết vào tệp nhật ký

Khóa bí mật của ứng dụng – Bạn phải đáp ứng 1 trong 2 điều kiện sau đây:

1. Tuyệt đối không tiết lộ khóa bí mật của ứng dụng ra ngoài môi trường máy chủ được bảo mật (ví dụ: khóa không bao giờ được trả về sau lệnh gọi mạng đến trình duyệt hoặc ứng dụng di động và không được nhúng vào mã phân phối đến ứng dụng di động hay ứng dụng gốc/trên máy tính)
2. Đặt cấu hình loại Gốc/Trên máy tính cho ứng dụng để API của Meta không còn tin tưởng các lệnh gọi API chứa khóa bí mật của ứng dụng

Hướng dẫn về bằng chứng

Nếu bạn được yêu cầu gửi bằng chứng về biện pháp bảo vệ này, hãy làm theo hướng dẫn trong mục Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai.

Vui lòng cung cấp tài liệu về chính sách bảo vệ khóa bí mật của ứng dụng Meta và mã truy cập API của Meta. Nếu ứng dụng xử lý mã truy cập của Meta tại phía máy chủ, hãy đưa ra bằng chứng cho thấy biện pháp bảo vệ mà bạn áp dụng (ví dụ: dùng kho lưu trữ, chứng minh rằng các giá trị được lưu trữ bằng định dạng mã hóa, đặt cấu hình để ứng dụng yêu cầu bằng chứng khóa bí mật của ứng dụng).

Bằng chứng mẫu

Một tổ chức dùng AWS Secrets Manager để lưu trữ an toàn dữ liệu nhạy cảm, bao gồm cả Khóa bí mật của ứng dụng Meta.

Một tổ chức đặt cấu hình để ứng dụng Meta mà họ sở hữu yêu cầu bằng chứng Khóa bí mật của ứng dụng cho các lệnh gọi API.

Biện pháp bảo vệ khác được chấp nhận

1. Nếu không bảo vệ mã truy cập lưu trữ tại phía máy chủ bằng kho lưu trữ dữ liệu hoặc thông qua tính năng mã hóa cấp ứng dụng, bạn có thể:
1. Bảo vệ khóa bí mật của ứng dụng bằng kho lưu trữ hoặc tính năng mã hóa cấp ứng dụng mà tại đó, khóa chỉ truy cập được vào ứng dụng
2. Đặt cấu hình để ứng dụng yêu cầu bằng chứng khóa bí mật của ứng dụng cho tất cả lệnh gọi API đến Meta
2. Nếu cách 1 ở trên không khả thi (tức là không thể yêu cầu bằng chứng khóa bí mật của ứng dụng do khi làm như vậy thì một số lệnh gọi API cần thiết sẽ bị chặn), Meta sẽ xem xét bất kỳ biện pháp kiểm soát nào khác mà bạn hiện có để hạn chế nguy cơ mã truy cập bị sử dụng trái phép thay vì nguy cơ mã truy cập lưu trữ bị lạm dụng

Lên kế hoạch ứng phó sự cố cũng như kiểm tra quy trình và hệ thống ứng phó sự cố

Câu hỏi: Bạn có kiểm tra các quy trình và hệ thống cần dùng để ứng phó với sự cố bảo mật (ví dụ: xâm phạm dữ liệu hoặc tấn công mạng) ít nhất 1 lần/năm không?

Ý định

Dù sớm hay muộn, sự cố bảo mật sẽ xảy ra với mọi công ty. Do đó, các tổ chức cần lên kế hoạch trước về việc ai cần làm gì để ngăn chặn sự cố, trao đổi với các bên liên quan, cũng như phục hồi và học hỏi từ sự cố đã xảy ra.

• Nếu sự cố bảo mật xảy ra, việc có sẵn kế hoạch hay cẩm nang cùng đội ngũ nhân sự được đào tạo về những việc cần làm có thể rút ngắn thời gian khắc phục sự cố và sau cùng là hạn chế tình trạng rò rỉ Dữ liệu trên nền tảng
• Dù rằng các tổ chức khác nhau sẽ có mức độ tinh vi khác nhau về ứng phó sự cố, chúng tôi yêu cầu ít nhất một kế hoạch cơ bản, trong đó nêu ra các hoạt động chính (phát hiện, ứng phó, phục hồi và xem lại) cùng với vai trò và trách nhiệm của nhân sự có tên được chỉ định

Tóm tắt các yêu cầu

Nhà phát triển phải có:

• Kế hoạch ứng phó sự cố đáp ứng các tiêu chí tối thiểu của Meta.
• Tài liệu này phải bao gồm (ít nhất): (1) vai trò và trách nhiệm, (2) phát hiện, (3) các bước ứng phó theo nghĩa vụ pháp lý hiện hành (ví dụ: thông báo về sự cố xâm phạm dữ liệu cho cơ quan giám sát và chủ thể dữ liệu phù hợp) cũng như phục hồi, (4) quy trình đánh giá sau sự cố
• Bằng chứng ghi lại rằng kế hoạch đã được kiểm tra gần đây (trong vòng 12 tháng qua) và tất cả các nhân viên có tên trong kế hoạch đã tham gia

Hướng dẫn về bằng chứng

Làm theo hướng dẫn trong mục Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai.

• Gửi kế hoạch ứng phó sự cố (một hoặc nhiều tài liệu). Kế hoạch này phải bao gồm những nội dung sau: vai trò và trách nhiệm, phát hiện, ứng phó và phục hồi cũng như đánh giá sau sự cố

  • Nếu chưa lên kế ứng phó sự cố, bạn có thể tham khảo nhiều thông tin và nguồn lực hữu ích trên Internet, chẳng hạn như mẫu kế hoạch ứng phó sự cố, Tài liệu tham khảo và nội dung đọc thêm của Counteractive
• Gửi bằng chứng cho thấy bạn đã kiểm tra kế hoạch trong vòng 12 tháng qua. Bằng chứng này có thể ở nhiều dạng, nhưng phải bao gồm:

  • Nội dung mô tả tình huống (ví dụ: diễn tập trong phòng họp về việc ứng phó sự cố tấn công từ phần mềm tống tiền),
  • Ngày tiến hành kiểm tra
  • Vai trò của từng người tham gia và
  • Lý do của từng nhân viên nếu bất kỳ nhân viên nào có tên trong phần vai trò và trách nhiệm của kế hoạch không tham gia
• Vui lòng loại bỏ thông tin nhạy cảm (ví dụ: thông tin nhận dạng cá nhân như tên và địa chỉ email) khỏi bằng chứng này trước khi gửi Bằng chứng mẫu

Kế hoạch ứng phó sự cố

Nhà phát triển đã tạo kế hoạch ứng phó sự cố toàn diện theo mẫu này. Những hình ảnh này chỉ mô tả mục lục nhưng có một liên kết bên dưới dẫn đến mẫu đầy đủ.

Hãy xem toàn bộ mẫu kế hoạch ứng phó sự cố của Counteractive (định dạng docx)

Kiểm tra kế hoạch ứng phó sự cố

Nhà phát triển đã tiến hành kiểm tra kế hoạch ứng phó sự cố thông qua diễn tập trong phòng họp, đồng thời đã ghi chép lại kết quả theo mẫu này.

Yêu cầu xác thực đa yếu tố đối với quyền truy cập từ xa

Câu hỏi: Bạn có yêu cầu xác thực đa yếu tố đối với quyền truy cập từ xa vào mọi tài khoản có thể kết nối với môi trường đám mây/máy chủ và/hoặc truy cập vào những dịch vụ bạn dùng để triển khai, duy trì, giám sát và vận hành các hệ thống lưu trữ Dữ liệu trên nền tảng của Meta không?

Ý định

Một kỹ thuật phổ biến mà các kẻ xấu sử dụng để giành quyền truy cập vào dữ liệu bí mật bắt đầu từ việc giành quyền truy cập vào các công cụ mà nhà phát triển dùng để xây dựng hoặc vận hành ứng dụng/hệ thống của họ. Các công cụ tinh vi ra đời với mục đích xâm nhập vào những tài khoản chỉ được bảo vệ bằng mật khẩu. Phương thức xác thực đa yếu tố bổ sung một lớp bảo mật giúp ngăn chặn nguy cơ này.

• Các nhà phát triển phần mềm sử dụng nhiều công cụ khác nhau để xây dựng, triển khai và quản trị các ứng dụng/hệ thống của họ
• Mọi người thường dùng các công cụ này từ xa qua Internet (ví dụ: nhân viên làm việc tại nhà và phân phối một tính năng phần mềm mới hoặc cập nhật cấu hình đám mây)
• Những công cụ được bảo vệ bằng phương thức xác thực 1 yếu tố (tên người dùng và mật khẩu) rất dễ bị tấn công chiếm đoạt tài khoản. Ví dụ: những kẻ tấn công có thể sử dụng các công cụ để thử đăng nhập bằng tổ hợp tên người dùng và mật khẩu đã bị rò rỉ từ một công cụ nhằm giành quyền truy cập vào một công cụ khác
• Phương thức xác thực đa yếu tố ngăn chặn các cuộc tấn công đó bằng cách yêu cầu một yếu tố khác bên cạnh mật khẩu khi đăng nhập, chẳng hạn như mã do ứng dụng xác thực tạo

Tóm tắt các yêu cầu

Về việc xử lý Dữ liệu trên nền tảng, tổ chức phải bảo vệ quyền truy cập từ xa vào các công cụ này bằng phương thức xác thực đa yếu tố (tức là không chỉ dùng mật khẩu):

• Các công cụ dùng để triển khai và quản lý những thay đổi về mã/cấu hình đối với ứng dụng/hệ thống
• Quyền truy cập quản trị vào môi trường đám mây hoặc máy chủ (nếu có)

Cụ thể, bạn cần sử dụng phương thức xác thực đa yếu tố (MFA) hoặc biện pháp bảo vệ khác được chấp nhận cho những công cụ sau:

• Công cụ cộng tác/liên lạc – ví dụ: email doanh nghiệp hay Slack
• Kho lưu trữ mã – ví dụ: GitHub hoặc công cụ khác dùng để theo dõi các thay đổi về mã/cấu hình của ứng dụng/hệ thống
• Nếu bạn xử lý Dữ liệu trên nền tảng tại phía máy chủ:

  • Công cụ triển khai phần mềm – các công cụ nhằm triển khai mã vào môi trường đám mây/máy chủ, chẳng hạn như Jenkins hoặc công cụ Tích hợp liên tục/Triển khai liên tục (CI/CD) khác
  • Công cụ quản trị – cổng thông tin hoặc quyền truy cập khác nhằm quản lý/giám sát môi trường đám mây/máy chủ
  • Quyền truy cập từ xa vào máy chủ – giao thức SSH, máy tính từ xa hoặc công cụ tương tự dùng để đăng nhập từ xa vào máy chủ chạy phía máy chủ

Về biện pháp triển khai phương thức xác thực đa yếu tố:

• Tổ chức nên dùng và ưu tiên dùng ứng dụng hoặc thiết bị phần cứng xác thực (ví dụ: YubiKey) cho các mã gửi bằng SMS
• Tuy nhiên, các tổ chức có thể áp dụng bất kỳ biện pháp nào để triển khai phương thức xác thực đa yếu tố

Hướng dẫn về bằng chứng

Nếu bạn được yêu cầu gửi bằng chứng về biện pháp bảo vệ này, hãy làm theo hướng dẫn trong phần Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai.

• Bằng chứng triển khai cần cho thấy đã trang bị phương thức xác thực đa yếu tố trên các công cụ được liệt kê trước đó mà sử dụng trong môi trường (tức là công cụ cộng tác, kho lưu trữ mã, công tác triển khai trên đám mây/máy chủ, cổng thông tin quản trị trên đám mây/máy chủ, quyền truy cập từ xa vào đám mây/máy chủ)
• Bằng chứng triển khai sẽ khác nhau tùy theo cấu hình:

  • Ví dụ: nếu bạn đang sử dụng nhà cung cấp dịch vụ Đăng nhập một lần (SSO) thì bằng chứng này có thể là ảnh chụp màn hình cấu hình chung của tổ chức hoặc ảnh chụp màn hình cấu hình của từng ứng dụng.
  • Nếu bạn không sử dụng nhà cung cấp SSO thì bằng chứng này có thể là ảnh chụp màn hình cấu hình của một công cụ cụ thể
• Dù là trường hợp nào, chúng tôi cần có bằng chứng cho thấy phương thức xác thực đa yếu tố được triển khai cho tất cả người dùng, chứ không phải chỉ một ví dụ về tài khoản đã triển khai phương thức này

Ví dụ về bằng chứng

AzureAD

Một tổ chức sử dụng AzureAD làm giải pháp Đăng nhập một lần. Chính sách này yêu cầu Xác thực đa yếu tố.

Sau đó, chính sách được liên kết với các ứng dụng trên đám mây áp dụng chính sách. Nếu bạn dùng phương pháp này, bằng chứng phải cho thấy toàn bộ phần Các mục đã chọn để trình bày rõ ứng dụng nào trên đám mây yêu cầu xác thực đa yếu tố.

Okta

Quy tắc này yêu cầu xác thực đa yếu tố đối với mọi lần đăng nhập.

AWS IAM

Đây là ví dụ về chính sách AWS IAM cho phép đặt cấu hình xác thực đa yếu tố (MFA), nhưng cấm các hành động khác nếu không triển khai MFA.

GitHub

Một tổ chức đặt cấu hình xác thực trên GitHub để yêu cầu xác thực đa yếu tố đối với mọi người dùng trong tổ chức.

Biện pháp bảo vệ khác được chấp nhận

• Đối với bất kỳ hình thức truy cập từ xa nào trong tổ chức mà không triển khai xác thực đa yếu tố, bạn cần mô tả nếu đang sử dụng một hoặc nhiều biện pháp sau đây để ngăn chặn hành vi chiếm đoạt tài khoản:

  • Yêu cầu mật khẩu mạnh – ví dụ: độ phức tạp tối thiểu của mật khẩu, cấm dùng các từ trong từ điển, cấm dùng mật khẩu từng bị rò rỉ
  • Trì hoãn xác thực – dùng công cụ tăng dần thời gian đợi sau mỗi lần cố đăng nhập không thành công từ cùng một nguồn
  • Tự động khóa tài khoản – ví dụ: cơ chế tự động ngăn đăng nhập vào tài khoản sau 10 lần đăng nhập không thành công

Thiết lập hệ thống bảo trì tài khoản người dùng

Câu hỏi: Bạn có thiết lập hệ thống bảo trì tài khoản (chỉ định, thu hồi, xem xét quyền truy cập và đặc quyền) không?

Ý định

Phương pháp quản lý tài khoản hiệu quả là yếu tố quan trọng nhằm ngăn hành vi sử dụng trái phép tài khoản để giành quyền truy cập vào Dữ liệu trên nền tảng. Đặc biệt, nhà phát triển phải đảm bảo việc thu hồi quyền truy cập vào nguồn lực hoặc hệ thống khi không còn cần thiết.

• Tài khoản là đơn vị quản lý cơ bản nhằm cấp cho người nào đó quyền truy cập vào hệ thống, dữ liệu và các chức năng quản trị
• Tài khoản được cấp quyền triển khai các hành động cụ thể. Một cách hiệu quả là chỉ cấp quyền tối thiểu mà tài khoản cần – đây gọi là nguyên tắc đặc quyền tối thiểu
• Khi một người rời khỏi tổ chức, tài khoản người dùng của họ phải bị vô hiệu hóa ngay vì một số lý do như sau:

  • (1) để ngăn người đó (tức là nhân viên cũ) truy cập và
  • (2) để hạn chế khả năng người không được cấp phép có thể sử dụng tài khoản mà không bị phát hiện. Ví dụ: kẻ xấu có thể sử dụng hình thức tấn công phi kỹ thuật để khiến bộ phận trợ giúp về CNTT đặt lại mật khẩu cho tài khoản. Nếu tài khoản này thuộc về nhân viên đang làm việc tại tổ chức thì nhân viên đó có thể sẽ báo cáo việc không thể đăng nhập. Tuy nhiên, nếu tài khoản đó vẫn đang hoạt động nhưng lại thuộc về nhân viên đã nghỉ việc thì sẽ ít được lưu tâm hơn.
• Vì vậy, các tổ chức phải có cách mang tính hệ thống để quản lý tài khoản, cấp quyền hoặc đặc quyền và thu hồi quyền truy cập khi không còn cần thiết

Tóm tắt các yêu cầu

• Bạn phải có công cụ hoặc quy trình quản lý tài khoản cho từng công cụ/hệ thống/ứng dụng cung cấp chức năng sau đây:

  • Liên lạc lẫn nhau, ví dụ: Slack hay email doanh nghiệp
  • Phân phối phần mềm, ví dụ: kho lưu trữ mã và
  • Quản trị và vận hành hệ thống (áp dụng cho quá trình xử lý Dữ liệu trên nền tảng)
• Bạn phải thường xuyên xem xét (tức là ít nhất 1 lần/năm) việc cấp quyền truy cập và phải có quy trình thu hồi quyền truy cập khi: (1) không còn cần thiết và (2) không còn được sử dụng
• Bạn cũng phải có quy trình để thu hồi ngay quyền truy cập vào các công cụ này khi một người rời khỏi tổ chức
• Meta không yêu cầu bạn dùng

  • Một công cụ nhất định nào – nhà phát triển có thể sử dụng sản phẩm thư mục như Google Cloud Identity hay Microsoft Azure Active Directory, sản phẩm đám mây như AWS Identity và Access Management (IAM) hoặc bảng tính được cập nhật thường xuyên.
  • Một công cụ tổng hợp duy nhất để quản lý các tài khoản có nhiều hình thức truy cập như trên.

Hướng dẫn về bằng chứng

Hãy làm theo hướng dẫn trong phần Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai.

• Bằng chứng về chính sách/quy trình – Cung cấp tài liệu về chính sách và quy trình cho thấy biện pháp quản lý tài khoản. Tài liệu này cần chứa các quy trình về cách tạo tài khoản, cấp quyền, độ phức tạp tối thiểu của mật khẩu, chính sách khóa tài khoản, chính sách xác thực đa yếu tố (MFA), quy trình đặt lại tài khoản cũng như quy trình thu hồi quyền truy cập sau một khoảng thời gian không hoạt động và khi có người rời khỏi tổ chức (ví dụ: khi nhân viên từ chức hoặc bị cho thôi việc).
• Bằng chứng triển khai – Cung cấp bằng chứng thông qua ít nhất một trong những công cụ/quy trình quản lý sẵn có sau đây đối với tài khoản (hoặc nêu rõ là không áp dụng cho môi trường): (1) Email doanh nghiệp và công cụ cộng tác, (2) Kho lưu trữ mã, (3) Công cụ triển khai trên đám mây/máy chủ, (4) Cổng thông tin quản trị trên đám mây/máy chủ, (5) Công cụ/quy trình đăng nhập từ xa vào đám mây/máy chủ (ví dụ: SSH hoặc máy tính từ xa). Đối với công cụ hoặc quy trình đại diện riêng biệt, hãy cung cấp bằng chứng cho thấy bạn đã:

  • Thu hồi quyền truy cập của những người rời khỏi tổ chức vào các công cụ này (ví dụ: báo cáo đối chiếu so sánh tài khoản người dùng với dữ liệu chính thống về các thành viên hiện tại của tổ chức)
  • Thu hồi quyền truy cập không được dùng đến trong một khoảng thời gian (ví dụ: báo cáo cho thấy nếu khoảng thời gian không hoạt động tối đa là 3 tháng thì ngày truy cập gần nhất của chủ tài khoản người dùng đại diện đang hoạt động sẽ nằm trong vòng 90 ngày vừa qua)

Ví dụ về bằng chứng

Bằng chứng về chính sách/quy trình – Một nhà phát triển tạo Tiêu chuẩn quản lý vòng đời truy cập chứa các quy trình cấp, xem xét và thu hồi quyền truy cập.

Ví dụ về bằng chứng triển khai – Thu hồi quyền truy cập của nhân sự đã rời khỏi tổ chức

Một nhà phát triển sử dụng Workday làm nguồn dữ liệu Quản trị nhân sự (HR) chính thống, bao gồm cả tình trạng việc làm hiện tại. Nhà phát triển này dùng Google Cloud Identity làm Nhà cung cấp danh tính (IdP) để quản lý tài khoản người dùng cũng như cấp quyền truy cập vào các công cụ và hệ thống thông tin.

Một nhà phát triển gửi bằng chứng về việc thu hồi quyền truy cập của nhân sự đã rời khỏi tổ chức thông qua báo cáo cho thấy gần đây đã chạy báo cáo đối chiếu (tức là trong 1 năm qua) và không phát hiện tài khoản người dùng không hoạt động nào trong Google Cloud Identity đối với những người không phải nhân viên đang hoạt động (theo báo cáo trên Workday về các nhân viên hiện tại).

Ví dụ về bằng chứng triển khai – Thu hồi quyền truy cập khi không còn dùng đến

Một nhà phát triển dùng Google Cloud Identity làm Nhà cung cấp danh tính (IdP) để quản lý tài khoản người dùng cũng như cấp quyền truy cập vào các công cụ và hệ thống thông tin.

Một nhà phát triển gửi bằng chứng cho thấy việc thu hồi quyền truy cập khi không còn dùng đến (ví dụ: không có lần đăng nhập nào trong 6 tháng qua) thông qua bằng chứng về thư mục người dùng được sắp xếp theo ngày đăng nhập gần nhất để thể hiện rằng không có tài khoản người dùng đang hoạt động nào có lần đăng nhập gần nhất trước thời gian này.

Ví dụ về bằng chứng triển khai – GitHub (Kho lưu trữ mã)

Một nhà phát triển sử dụng công cụ Đăng nhập một lần (SSO) để quản lý danh tính và cấp quyền truy cập vào các công cụ và hệ thống thông tin. Nhà phát triển này đã đặt cấu hình GitHub để yêu cầu xác thực SSO.

Luôn cập nhật phần mềm

Câu hỏi: Bạn có hệ thống cập nhật môi trường và mã hệ thống, chẳng hạn như máy chủ, máy ảo, phương thức phân phối, thư viện, gói và phần mềm diệt vi-rút không?

Ý định

Các thành phần của phần mềm được cập nhật hoặc vá thường xuyên nhằm khắc phục lỗ hổng bảo mật. Sau cùng, các thành phần này sẽ hết tuổi thọ khi không còn được hỗ trợ nữa. Các nhà phát triển kết hợp hoặc sử dụng những thành phần này phải đảm bảo cập nhật để tránh chạy phần mềm có các lỗ hổng bảo mật đã biết.

• Các nhà phát triển ứng dụng chạy ứng dụng/hệ thống xử lý Dữ liệu trên nền tảng dựa trên nhiều phần mềm của bên thứ ba
• Ví dụ: một nhà phát triển sẽ sử dụng một số hoặc toàn bộ các thành phần sau:

  • Thư viện, SDK, Gói – nhà phát triển kết hợp các thành phần này với mã tùy chỉnh của họ để xây dựng ứng dụng
  • Tệp ảnh đĩa Máy ảo, vùng chứa ứng dụng và hệ điều hành – ứng dụng chạy bên trong một hoặc nhiều vùng chứa này (cung cấp các dịch vụ như ảo hóa, đồng thời truy cập vào mạng và bộ nhớ)
  • Trình duyệt, hệ điều hành và các ứng dụng khác mà nhân viên/người đóng góp dùng – phần mềm chạy trên thiết bị di động và máy tính xách tay mà nhà phát triển sử dụng để xây dựng và chạy hệ thống của họ
• Các lỗ hổng bảo mật thường được tìm thấy trong những thành phần này, dẫn đến việc phát hành các bản vá
• Sau đó, các lỗ hổng bảo mật đã khắc phục bằng bản vá sẽ được tiết lộ trong cơ sở dữ liệu công khai kèm theo thứ tự xếp hạng về mức độ nghiêm trọng (thấp, trung bình, cao hoặc rất cao)
• Do đó, các nhà phát triển sử dụng nền tảng của Meta phải có phương pháp mang tính hệ thống để quản lý bản vá bằng cách

  • Xác định bản vá phù hợp với ứng dụng/hệ thống của họ
  • Ưu tiên tình huống cấp bách dựa trên mức độ rò rỉ và
  • Liên tục sử dụng bản vá trong hoạt động kinh doanh

Tóm tắt các yêu cầu

Đối với các thành phần sau đây của phần mềm (nếu có), bạn phải có cách xác định và dễ làm theo để xác định những bản vá có sẵn nhằm khắc phục lỗ hổng bảo mật, ưu tiên dựa trên mức độ nguy cơ và liên tục sử dụng bản vá trong quá trình hoạt động:

1. Thư viện, SDK, gói, vùng chứa ứng dụng và hệ điều hành dùng trong môi trường đám mây hoặc máy chủ
2. Thư viện, SDK, gói dùng trên thiết bị khách, chẳng hạn như trong ứng dụng di động
3. Hệ điều hành và các ứng dụng mà thành viên dùng để xây dựng và vận hành ứng dụng/hệ thống (ví dụ: hệ điều hành và trình duyệt chạy trên máy tính xách tay của nhân viên)

Meta không yêu cầu sử dụng công cụ cụ thể nào cho những hoạt động này. Thông thường, tổ chức sẽ sử dụng các phương pháp khác nhau để luôn cập nhật nhiều loại phần mềm (ví dụ: thư viện được đóng gói cùng bản cập nhật ứng dụng với bản cập nhật hệ điều hành cho máy tính xách tay của nhân viên).

Sơ đồ bên dưới minh họa trường hợp có thể cần phải vá cho nhiều loại kiến trúc.

Hướng dẫn về bằng chứng

Nếu bạn được yêu cầu gửi bằng chứng về biện pháp bảo vệ này, hãy làm theo hướng dẫn trong mục Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai.

Hãy bắt đầu bằng cách xác định các loại phần mềm trong phạm vi môi trường (ví dụ: Thư viện, SDK, Gói, tệp ảnh đĩa Máy ảo, vùng chứa ứng dụng và hệ điều hành), Trình duyệt, hệ điều hành và các ứng dụng khác mà nhân viên/người đóng góp dùng.

Bạn có thể sử dụng một hoặc nhiều công cụ cho những hoạt động sau:

• Danh mục – ghi chép thông qua ảnh chụp màn hình hay tài liệu mà cuối cùng, công cụ hoặc quy trình biểu thị một danh sách các thư viện, gói, SDK, vùng chứa, máy chủ ứng dụng và hệ điều hành trong phạm vi cần được vá. Cần có những danh mục biểu thị các loại phần mềm (ví dụ: (các) ứng dụng trên đám mây, (các) ứng dụng khách, thiết bị của nhân viên).
• Xác định các bản vá phần mềm có sẵn – phải có sẵn công cụ hoặc quy trình để xác định những bản vá bảo mật hiện có phù hợp với danh mục.
• Ưu tiên – cần có công cụ hoặc quy trình (ví dụ: yêu cầu trong Jira, GitHub Issues, bảng tính theo dõi), theo đó các bản vá phù hợp được chỉ định mức độ ưu tiên

  • Vá
  • Ghi chép thông qua ảnh chụp màn hình hoặc tài liệu cho thấy rằng sau khi xác định được và ưu tiên các bản vá phù hợp, những bản vá này sẽ được triển khai vào nhiều đích đến.
• Thêm các chính sách về thời gian để giải quyết và sử dụng phần mềm Không còn được hỗ trợ (EOL).

Bằng chứng mẫu

Snyk dành cho ứng dụng NodeJS – Nhà phát triển sử dụng Giao diện dòng lệnh (CLI) Synk để xác định những phần phụ thuộc của bên thứ ba được đóng gói có lỗ hổng bảo mật đã biết và ưu tiên dựa trên mức độ nghiêm trọng của những lỗ hổng bảo mật đó.

NPM Audit

Nhà phát triển đang sử dụng NPM Audit để phát hiện lỗ hổng bảo mật trong những phần phụ thuộc được dùng trong ứng dụng Node. Ảnh minh họa bên dưới cho thấy nhiều lỗ hổng bảo mật rất nghiêm trọng cần được vá.

Trivy

Nhà phát triển sử dụng Trivy để phát hiện các lỗ hổng bảo mật trong hình ảnh máy. Ảnh minh họa bên dưới cho thấy các lỗ hổng bảo mật rất nghiêm trọng cần được vá trong những thư viện thuộc hình ảnh này.

Windows Server Update Services (WSUS)

Nhà phát triển sử dụng Windows Server Update Services (WSUS) để quản lý nhóm máy chủ và máy tính/máy tính xách tay của họ. Ảnh minh họa bên dưới cho thấy chế độ xem quản trị của công cụ WUSU để xem xét, phê duyệt và triển khai các bản cập nhật Windows.

Thiết lập hệ thống ghi lại lượt truy cập vào Dữ liệu trên nền tảng cũng như truy dấu nơi gửi và lưu trữ Dữ liệu này

Ý định

Nếu thiếu các tệp nhật ký đáng tin cậy, nhà phát triển sẽ khó lòng hoặc không thể phát hiện hành vi truy cập trái phép vào Dữ liệu trên nền tảng.

• Nhật ký kiểm tra hỗ trợ tổ chức ghi lại việc một sự kiện đã xảy ra, chẳng hạn như người dùng nào đó thực hiện một truy vấn đối với bảng cơ sở dữ liệu chứa Dữ liệu trên nền tảng
• Khi đó, các nhật ký này có thể tạo điều kiện cho những quy trình như kích hoạt thông báo tự động khi có hoạt động đáng ngờ hoặc phân tích nguyên nhân sau khi xác định được sự cố bảo mật

Tóm tắt các yêu cầu

Nếu xử lý Dữ liệu trên nền tảng tại phía máy chủ thì trong môi trường đó, bạn nên:

• Duy trì nhật ký kiểm tra ghi lại các sự kiện chính (ví dụ: lượt truy cập vào Dữ liệu trên nền tảng, hành động sử dụng tài khoản có quyền cao hơn, những thay đổi về cấu hình nhật ký kiểm tra)
• Hợp nhất nhật ký kiểm tra thành một kho lưu trữ tập trung và thực hiện các biện pháp ngăn ngừa hành vi thay đổi hoặc xóa

Hướng dẫn về bằng chứng

Bằng chứng bạn tải lên khi có yêu cầu cần cho thấy:

• Bạn nắm rõ thông tin hiện tại về cách Dữ liệu trên nền tảng được lưu trữ, truy cập và chuyển đi, chẳng hạn như qua sơ đồ luồng dữ liệu hiện tại phản ánh cái nhìn tổng thể về hệ thống, cho biết những dịch vụ lưu trữ Dữ liệu trên nền tảng cũng như biểu thị các điểm vào và ra, bao gồm cả phương pháp chuyển thích hợp sang bất kỳ dịch vụ bên thứ tư nào
• Bạn đã triển khai nhật ký kiểm tra ngăn ngừa hành vi xâm nhập
• Nhật ký ghi lại các sự kiện liên quan đến lượt truy cập vào dữ liệu trên nền tảng

Giám sát hoạt động chuyển Dữ liệu trên nền tảng và các điểm quan trọng nơi Dữ liệu trên nền tảng có thể rời khỏi hệ thống (ví dụ: bên thứ ba, điểm cuối công cộng)

Ý định

Tổ chức phải biết phương pháp xử lý thích hợp đối với Dữ liệu trên nền tảng rồi giám sát quy trình xử lý thực tế để đảm bảo rằng Dữ liệu trên nền tảng chỉ được dùng cho các mục đích đã đề ra

• Nhà phát triển cần nắm rõ thông tin hiện tại về cách Dữ liệu trên nền tảng được lưu trữ, truyền qua mạng và ghi vào bản sao lưu (có thể xuất hiện ở nơi khác nữa)
• Ví dụ: hoạt động giám sát có thể xác định tình huống Dữ liệu trên nền tảng đang được truyền theo cách không mong muốn hoặc truyền qua mạng mà không áp dụng phương thức mã hóa phù hợp khi truyền để bạn đưa ra biện pháp xử lý

Tóm tắt các yêu cầu

Nếu xử lý Dữ liệu trên nền tảng tại phía máy chủ thì trong môi trường máy chủ đó, bạn nên:

• Duy trì sơ đồ luồng dữ liệu chính xác cho biết nơi Dữ liệu trên nền tảng được lưu trữ, xử lý và truyền qua mạng
• Đặt cấu hình giám sát (ví dụ: nhật ký kiểm tra bằng sản phẩm giám sát tự động) để chuyển Dữ liệu trên nền tảng ra bên ngoài hệ thống
• Đặt cấu hình (nếu có thể) hệ thống giám sát để đưa ra cảnh báo kịp thời trong trường hợp Dữ liệu trên nền tảng được chuyển đi theo cách không mong muốn (hãy xem thêm yêu cầu bên dưới – Thiết lập hệ thống tự động để giám sát nhật ký và các sự kiện bảo mật khác, cũng như để tạo cảnh báo về các sự kiện bất thường hoặc liên quan đến bảo mật)

Hướng dẫn về bằng chứng

Nếu bạn được yêu cầu gửi bằng chứng về biện pháp bảo vệ này, hãy làm theo hướng dẫn trong mục Chuẩn bị bằng chứng để chuẩn bị cả bằng chứng về chính sách/quy trình và bằng chứng triển khai.

Vui lòng cung cấp bằng chứng cho thấy:

• Bạn nắm rõ thông tin hiện tại về cách Dữ liệu trên nền tảng được lưu trữ, truy cập và chuyển đi, chẳng hạn như qua sơ đồ luồng dữ liệu hiện tại phản ánh cái nhìn tổng thể về hệ thống, cho biết những dịch vụ lưu trữ Dữ liệu trên nền tảng cũng như biểu thị các điểm vào và ra, bao gồm cả phương pháp chuyển thích hợp sang bất kỳ dịch vụ bên thứ tư nào
• Nhật ký kiểm tra ngăn ngừa hành vi xâm nhập đã được triển khai
• Nhật ký có ghi lại các sự kiện liên quan đến hoạt động chuyển Dữ liệu trên nền tảng, bao gồm thông tin về thời gian, danh tính người dùng hoặc ứng dụng thực hiện hành động, nguồn và đích đến

Thiết lập hệ thống tự động để giám sát nhật ký và các sự kiện bảo mật khác, cũng như để tạo cảnh báo về các sự kiện bất thường hoặc liên quan đến bảo mật

Ý định

Bạn không thể chỉ dựa vào con người để đánh giá và xác định hành vi không mong muốn trong hệ thống truy cập Internet hiện đại. Thay vào đó, bạn có sẵn các công cụ hỗ trợ xử lý tệp nhật ký và các tín hiệu khác để đưa ra những cảnh báo cần được con người điều tra thêm.

Tóm tắt các yêu cầu

Nếu xử lý Dữ liệu trên nền tảng tại phía máy chủ thì trong môi trường máy chủ đó, bạn nên:

• Sở hữu công cụ có khả năng xử lý các tệp nhật ký và sự kiện khác, thiết lập các quy tắc mà sẽ đưa ra cảnh báo nếu được kích hoạt, cũng như cơ chế gửi cảnh báo đến nhân viên (ví dụ: một chuyên viên điều tra bảo mật luôn túc trực sẵn sàng)
• Đưa các tín hiệu có liên quan vào công cụ (ví dụ: nhật ký truy cập web, số lần cố xác thực, hành động của người dùng có đặc quyền nâng cao)
• Điều chỉnh và tinh chỉnh các quy tắc theo thời gian để cân bằng tín hiệu với nhiễu (ví dụ: bằng việc tránh đưa ra quá nhiều cảnh báo giả, nhưng cũng không bỏ qua các sự kiện cần điều tra)

Hướng dẫn về bằng chứng

Thông thường, nhà phát triển sẽ sử dụng công cụ Quản lý sự kiện và thông tin bảo mật (SIEM) cho mục đích này, chẳng hạn như:

• McAfee Enterprise Security Manager
• SolarWinds Security Event Manager
• Splunk Enterprise Security
• Sumo Logic

Bạn cần cung cấp bằng chứng cho thấy các nguồn tín hiệu liên quan được gửi đến công cụ phù hợp, các yếu tố kích hoạt hoặc cảnh báo được đặt cấu hình, các cảnh báo được gửi đến nhân viên chịu trách nhiệm theo dõi, cũng như có quy trình điều chỉnh cảnh báo định kỳ (ví dụ: qua chu kỳ cập nhật và đánh giá hàng tháng).

Bảng thuật ngữ

A

Bên thứ ba – trong thuật ngữ về quản lý rủi ro, bên thứ ba là nhà phát triển trên nền tảng của Meta (bên thứ nhất chính là Meta; bên thứ hai là người dùng sản phẩm của Meta)

Bên thứ tư – trong thuật ngữ về quản lý rủi ro, bên thứ tư là những công ty mà nhà phát triển tin dùng cho việc cung cấp các dịch vụ hỗ trợ hoạt động kinh doanh (bên thứ nhất là Meta, bên thứ hai là người dùng của Meta và bên thứ ba là nhà phát triển trên nền tảng của Meta) Mã truy cập – thông tin đăng nhập (chẳng hạn như mật khẩu) cần có để phần mềm gọi API nhằm thực hiện hành động nào đó (ví dụ: đọc dữ liệu từ trang cá nhân của người dùng).

Amazon Web Services (AWS) – bộ dịch vụ điện toán đám mây của Amazon

ID người dùng trong ứng dụng (ASID) – mã nhận dạng duy nhất do Meta tạo khi người nào đó chọn dùng một ứng dụng. ASID góp phần cải thiện quyền riêng tư cho người dùng bằng cách khiến các tập dữ liệu khó xác định mối tương quan về người dùng giữa các ứng dụng hơn. Lý do là khi dùng 2 ứng dụng, một người sẽ có các ASID khác nhau trong từng ứng dụng đó.

Khóa bí mật của ứng dụng – khóa bí mật chung do Meta cung cấp cho nhà phát triển thông qua bảng điều khiển ứng dụng. Khi sở hữu khóa bí mật của ứng dụng, phần mềm có quyền thực hiện một số hành động thông qua API Đồ thị. Do đó, nhà phát triển cần lưu ý rằng những bên chưa được cấp phép sẽ không thể truy cập vào khóa bí mật của ứng dụng.

Xâm phạm ứng dụng – nếu kẻ xấu có thể truy cập trái phép vào mạng nội bộ của tổ chức do cấu hình sai hoặc lỗ hổng bảo mật trong ứng dụng (ví dụ: lỗ hổng bảo mật phần mềm trong ứng dụng web) thì đó gọi là hành vi xâm phạm ứng dụng. Một biện pháp để ngăn ngừa hành vi xâm phạm ứng dụng là kiểm thử thâm nhập ứng dụng. Hãy xem thêm thuật ngữ xâm phạm mạng.

Vùng chứa ứng dụng – vùng chứa đóng gói mã phần mềm và những yếu tố phụ thuộc có liên quan để ứng dụng chạy trên các loại máy chủ khác nhau (ví dụ: những máy chủ chạy các hệ điều hành khác nhau như Linux hoặc Windows Server). Nhà phát triển sẽ tạo một hình ảnh vùng chứa đóng gói ứng dụng của họ. Công cụ vùng chứa ứng dụng hoặc thành phần vùng chứa ứng dụng sẽ lưu trữ (chạy) hình ảnh vùng chứa.

Mã hóa ứng dụng – một phương thức bảo vệ dữ liệu, theo đó phần mềm ứng dụng tự thực hiện các hoạt động mã hóa và giải mã. Ngược lại, Transport Layer Security (TLS) sẽ mã hóa liền mạch dữ liệu đang truyền khi ứng dụng thiết lập một kết nối an toàn với máy chủ từ xa (ví dụ: dùng HTTPS) và nhà cung cấp dịch vụ đám mây đưa ra dịch vụ để mã hóa minh bạch dữ liệu ở trạng thái nghỉ.

Giao diện lập trình ứng dụng (API) – đóng vai trò kết nối 2 máy tính qua mạng, ví dụ như khi một ứng dụng di động tìm nạp thông tin thời tiết hôm nay ở nơi nào đó từ hệ thống dự báo thời tiết tập trung

Bằng chứng khóa bí mật của ứng dụng – một lớp bảo mật bổ sung cho các lệnh gọi API đến Meta, theo đó nhà phát triển sẽ tạo tham số (bằng chứng khóa bí mật của ứng dụng) chứng minh rằng họ sở hữu khóa bí mật của ứng dụng. Bằng chứng khóa bí mật của ứng dụng là sản phẩm của hàm băm (còn gọi là hàm một chiều) dựa trên khóa bí mật của ứng dụng và mã truy cập. Việc đặt cấu hình để ứng dụng yêu cầu bằng chứng khóa bí mật của ứng dụng trong quá trình gọi API Đồ thị sẽ làm giảm mối nguy hại có thể xảy ra do mã truy cập của người dùng bị xâm phạm, vì không ai có thể sử dụng những mã truy cập đó nếu không xuất trình thêm thông số bằng chứng khóa bí mật của ứng dụng.

B

Giải pháp phụ trợ dạng dịch vụ (BaaS) – một mô hình điện toán đám mây cung cấp bộ tính năng phía máy chủ cho nhà phát triển ứng dụng để họ có thể tập trung vào việc xây dựng giao diện trải nghiệm (tức là phần ứng dụng mà người dùng tương tác). Các giải pháp BaaS không chỉ tương tự PaaS mà còn có những dịch vụ như xác thực người dùng và thông báo đẩy trên thiết bị di động. Sau đây là ví dụ về một số sản phẩm BaaS phổ biến: AWS Amplify, Azure Mobile Apps, Firebase và MongoDB Switch.

C

Văn bản mật mã – đồng nghĩa với dữ liệu mã hóa và là dữ liệu được chuyển đổi thông qua thuật toán mã hóa thành dạng không đọc được. Ngược lại với văn bản mật mã là văn bản thuần túy.

Phía máy khách – mọi người thường tương tác với các dịch vụ có thể truy cập vào Internet bằng cách mở trang web trong trình duyệt hoặc chạy ứng dụng di động trên điện thoại hay máy tính bảng. Trình duyệt hoặc ứng dụng di động được gọi là máy khách cục bộ hoặc phía máy khách. Máy khách thực hiện yêu cầu của máy tính từ xa (máy chủ) thông qua Internet.

Điện toán đám mây – một mô hình quản lý máy chủ, mạng và bộ nhớ để tổ chức không cần phải lo lắng về môi trường vật lý (tức là trung tâm dữ liệu có đầy đủ giá đỡ máy chủ và cáp mạng). Thay vào đó, tổ chức có thể cung cấp những tài sản này theo yêu cầu và trả tiền cho dịch vụ họ dùng.

Cấu hình đám mây – tập hợp các lựa chọn điện toán đám mây mà tổ chức thiết lập liên quan đến việc họ dùng một nhà cung cấp dịch vụ đám mây để chạy phần mềm nào đó. Ví dụ về cấu hình đám mây bao gồm loại kết nối mạng được phép hoặc bị chặn, nơi ghi và thời gian lưu giữ tệp nhật ký, nhóm người dùng có quyền thực hiện thay đổi đối với cấu hình đám mây.

Biện pháp kiểm soát thay thế – biện pháp kiểm soát bảo mật nằm ngoài bộ yêu cầu cơ bản nhưng nhằm cung cấp khả năng bảo vệ tương đương trước rủi ro.

D

Cơ sở dữ liệu – phần mềm dùng để lưu trữ, đọc, cập nhật và xóa loại dữ liệu tùy ý. Cơ sở dữ liệu có thể chạy trên máy khách và máy chủ. Những tổ chức tích hợp với nền tảng của Meta thường sẽ lưu trữ dữ liệu họ tìm nạp từ API Đồ thị trong cơ sở dữ liệu chạy phía máy chủ.

Giải mã – quy trình chuyển đổi dữ liệu mã hóa về định dạng gốc. Nói cách khác, quy trình giải mã sẽ biến văn bản mật mã thành văn bản thuần túy.

E

Mã hóa – quy trình chuyển đổi dữ liệu thành định dạng không dùng được đối với bất kỳ ai không thể giải mã. Nói cách khác, quy trình mã hóa sẽ biến văn bản thuần túy thành văn bản mật mã.

Mã hóa ở trạng thái nghỉ – phương thức bảo vệ dữ liệu bằng tính năng mã hóa khi dữ liệu đó được ghi vào bộ nhớ liên tục (ví dụ: ổ đĩa). Phương thức này sẽ bổ sung một lớp bảo vệ nhằm ngăn ngừa hành vi truy cập trái phép vì người có thể đọc tệp thô trên thiết bị lưu trữ sẽ nhìn thấy nhưng không thể giải mã văn bản mật mã, trừ khi họ cũng truy cập được vào khóa giải mã.

Mã hóa khi truyền – phương thức bảo vệ dữ liệu bằng tính năng mã hóa khi truyền qua mạng. Phương thức này sẽ ngăn ngừa hành vi nghe trộm theo đường dẫn mạng vì người có thể đọc gói tin qua mạng sẽ nhìn thấy nhưng không thể giải mã văn bản mật mã, trừ khi họ cũng truy cập được vào khóa giải mã.

Phần mềm hết hạn sử dụng (EOL) – khi tổ chức chọn ngừng hỗ trợ (ví dụ: tạo bản vá để giải quyết lỗ hổng bảo mật) cho một sản phẩm phần mềm thì phần mềm đó được xem là EOL. Vì không còn được duy trì nên bất kỳ phần mềm EOL nào như vậy sẽ gặp rủi ro cao khi chạy.

G

Google Cloud Platform (GCP) – bộ dịch vụ điện toán đám mây của Google. API Đồ thị – phương thức chính để các ứng dụng đọc và ghi vào đồ thị mạng xã hội của Meta. Mọi Meta SDK và sản phẩm của Meta đều tương tác với API Đồ thị theo cách nào đó.

H

Hàm băm – hàm mã hóa lấy dữ liệu bất kỳ làm thông tin đầu vào và xuất thành một mã ngắn không thể hoàn nguyên về định dạng gốc. Trong lĩnh vực mã hóa, hàm băm dùng để bảo vệ dữ liệu như mật khẩu – thay vì lưu trữ mật khẩu của người dùng dưới dạng văn bản thuần túy có thể bị đánh cắp, trước tiên mật khẩu sẽ trải qua quy trình chuyển đổi bằng hàm băm rồi mới được lưu trữ. Sau đó, để xác nhận rằng người dùng đã nhập đúng mật khẩu, hệ thống sẽ sử dụng chính hàm băm này để chuyển đổi thông tin đầu vào và so sánh mã băm thu được với giá trị lưu trữ. Đây còn gọi là hàm một chiều vì mã băm đầu ra không thể hoàn nguyên về định dạng gốc.

Môi trường lưu trữ – tập hợp các máy chủ từ xa, mạng và thiết bị lưu trữ mà tổ chức đang chạy trong trung tâm dữ liệu của riêng họ hoặc trung tâm dữ liệu cho thuê cùng với các khách hàng khác. Đây là cơ chế sắp xếp ít gặp trong kỷ nguyên hiện đại kể từ khi dịch vụ điện toán đám mây ngày càng phổ biến.

I

Dịch vụ cung cấp danh tính (IdP) – một dịch vụ đám mây dùng để quản lý tập trung danh tính kỹ thuật số và xác thực người dùng. Các tổ chức dùng IdP thường đặt cấu hình ứng dụng đám mây dựa trên IdP để xác thực người dùng. Sau đó, tổ chức có thể quản lý người dùng bằng cách tạo, cấp quyền truy cập vào những ứng dụng nhất định và vô hiệu hóa tài khoản người dùng ở cùng một nơi là IdP thay vì phải làm như vậy nhiều lần trong từng ứng dụng đám mây.

Quản lý danh tính và quyền truy cập (IAM) – một nhóm các công cụ và quy trình dùng để quản lý tài khoản cũng như cấp quyền truy cập vào hệ thống.

Cơ sở hạ tầng dạng dịch vụ (IaaS) – một phương pháp điện toán đám mây hỗ trợ khách hàng đặt cấu hình các dịch vụ điện toán, lưu trữ và kết nối mạng mà không phải chịu trách nhiệm về chính những tài sản vật lý (ví dụ: quản lý trung tâm dữ liệu có đầy đủ máy chủ, thiết bị mạng và mảng lưu trữ). So với Paas, IaaS mang lại cho tổ chức thêm nhiều quyền kiểm soát về cấu hình của các tài sản đám mây mà họ sở hữu. Đổi lại, việc quản lý những tài sản đó sẽ phức tạp hơn. Sau đây là ví dụ về một số sản phẩm IaaS phổ biến: AWS EC2, Microsoft Azure IaaS và Google Compute Engine.

L

Thư viện – các thành tố nền tảng có sẵn cho phần mềm, thường đến từ công ty hoặc nhà phát triển bên ngoài, dùng để xử lý những tác vụ nhất định trong ứng dụng hay hệ thống của nhà phát triển khác. Thư viện tinh giản việc phát triển ứng dụng vì nhà phát triển không phải tốn công sáng tạo lại khi đã có thư viện cung cấp chức năng cụ thể. Tuy nhiên, thư viện có thể chứa lỗ hổng bảo mật hoặc bao gồm các thư viện khác gặp phải vấn đề như vậy. Do đó, nhà phát triển cần nắm rõ mình đang dùng thư viện nào cho ứng dụng và cập nhật thư viện này theo thời gian.

M

Ứng dụng di động – ứng dụng mà người nào đó cài đặt trên điện thoại hoặc máy tính bảng sau khi tải về từ cửa hàng ứng dụng di động (ví dụ: App Store dành cho iOS hoặc Cửa hàng Google Play). Ứng dụng di động thường liên lạc qua Internet với REST API của tổ chức và cũng có thể sẽ giao tiếp với các bên khác (ví dụ: với API Đồ thị qua Facebook SDK dành cho Android).

Xác thực đa yếu tố (MFA) – một phương pháp xác thực yêu cầu nhiều yếu tố để cấp quyền truy cập vào ứng dụng hoặc hệ thống. Ngược lại với phương pháp xác thực 1 yếu tố chỉ dựa vào mật khẩu để xác thực người dùng, MFA thường sẽ yêu cầu mật khẩu kèm theo một hoặc nhiều yếu tố sau đây: mã được gửi qua email hoặc SMS, mã từ ứng dụng xác thực, quy trình quét sinh trắc học hoặc khóa bảo mật. MFA khiến người chưa được cấp phép khó xâm nhập tài khoản hơn (ví dụ: dùng địa chỉ email mà họ biết được và mật khẩu phổ biến để liên tục cố đăng nhập vào tài khoản cho đến khi thành công) nhằm ngăn ngừa hành vi chiếm đoạt tài khoản.

N

Phần mềm gốc – những ứng dụng được tải xuống và cài đặt trên laptop hoặc thiết bị di động (ví dụ: ứng dụng Facebook dành cho iOS). Ngược lại, ứng dụng chạy trong trình duyệt được gọi là ứng dụng web (ví dụ: mở Facebook bằng trình duyệt Chrome).

Xâm phạm mạng – nếu kẻ xấu có thể truy cập trái phép vào mạng nội bộ của tổ chức do cấu hình sai hoặc lỗ hổng bảo mật trong mạng thì đó gọi là hành vi xâm phạm mạng. Một biện pháp giúp ngăn ngừa hành vi xâm phạm mạng là chạy quy trình quét mạng để xác định những cấu hình sai và lỗ hổng bảo mật trong mạng kết nối Internet. Hãy xem thêm thuật ngữ "xâm phạm ứng dụng".

Quét mạng – quy trình quản lý rủi ro dùng phần mềm để: (1) xác định những máy chủ đang hoạt động trên mạng sẽ phản hồi với nội dung liên lạc từ xa rồi (2) xem có bất kỳ máy chủ nào trong số đó đang chạy phiên bản phần mềm cũ được cho là dễ bị tấn công bởi một hoặc nhiều phương pháp lợi dụng lỗ hổng bảo mật hay không. Ví dụ: tổ chức có thể dùng tính năng quét mạng định kỳ để đảm bảo rằng không có cổng nào vô tình mở trong phạm vi mạng của họ.

Công cụ quản lý gói Node (NPM) – một công cụ mà nhà phát triển JavaScript dùng để đẩy nhanh quy trình làm việc bằng cách đưa những gói được tạo sẵn vào ứng dụng hoặc hệ thống của họ. NPM cung cấp tính năng kiểm tra nhóm các gói mà ứng dụng đang dùng và xác định những gói có lỗ hổng bảo mật đã biết.

O

Vùng lưu trữ đối tượng – một loại bộ nhớ liên tục trên đám mây, có chức năng hỗ trợ tổ chức dễ dàng lưu trữ tệp vào bộ nhớ liên tục (bao gồm cả tệp có dung lượng rất lớn) mà không phải lo lắng về việc mở rộng tài sản vật lý (ví dụ: mảng lưu trữ) hoặc cách sao lưu để tránh bị mất những tệp này trong trường hợp xảy ra thiên tai như hỏa hoạn hay lũ lụt.

Hệ điều hành – phần mềm chạy trên máy tính/thiết bị di động, có chức năng tạo điều kiện để các ứng dụng chạy cũng như dùng bộ xử lý, bộ nhớ, dung lượng lưu trữ và nguồn lực mạng của máy tính/thiết bị di động đó. Ví dụ: Windows của Microsoft, macOS hoặc iOS của Apple, Linux.

Thành viên tổ chức – người có vai trò và trách nhiệm trong tổ chức, ví dụ: nhân viên, nhà thầu, nhân viên không chính thức, thực tập sinh hoặc tình nguyện viên.

Thiết bị trong tổ chức – máy tính hoặc thiết bị di động mà thành viên tổ chức dùng để làm việc cho tổ chức.

P

Điều khoản nền tảng 6.a.i – điểm (i) khoản (a) điều (6) trong Điều khoản nền tảng của Meta, mô tả các nghĩa vụ của nhà phát triển trên nền tảng liên quan đến bảo mật dữ liệu.

Gói – đồng nghĩa với thư viện

Bản vá – bản cập nhật của phần mềm, có nhiệm vụ giải quyết lỗ hổng bảo mật, khắc phục lỗi hoặc thêm chức năng mới. Mọi loại phần mềm đều có bản vá, bao gồm cả Hệ điều hành, vùng chứa, thư viện và SDK.

Kiểm thử thâm nhập – một cuộc tấn công mô phỏng nhắm đến ứng dụng hoặc hệ thống, qua đó người kiểm thử cố gắng tìm lỗ hổng bảo mật trong mã hoặc cấu hình có thể bị lợi dụng bởi người chưa được cấp phép. Người kiểm thử thâm nhập sẽ dùng các công cụ tương tự như tội phạm công nghệ cao để tiến hành do thám, quét tìm điểm yếu tiềm ẩn và kiểm thử những lỗ hổng bảo mật có thể tạo điều kiện cho hành vi truy cập trái phép. Cuối quy trình kiểm thử thâm nhập, người kiểm thử sẽ soạn một báo cáo mô tả thông tin phát hiện được cùng với mức độ nghiêm trọng của từng vấn đề. Ngoài ra, tổ chức duy trì phần mềm sẽ chịu trách nhiệm tạo bản khắc phục để giải quyết lỗ hổng bảo mật.

Văn bản thuần túy – đồng nghĩa với dữ liệu không mã hóa và là dữ liệu chưa được bảo vệ bằng tính năng mã hóa. Nền tảng dạng dịch vụ (PaaS) – một phương pháp điện toán đám mây hỗ trợ khách hàng triển khai ứng dụng vào nền tảng do nhà cung cấp dịch vụ đám mây quản lý. Khách hàng dễ quản lý PaaS hơn so với IaaS vì trung tâm lưu trữ đám mây không chỉ quản lý tài sản vật lý (tức là máy chủ, thiết bị lưu trữ và thiết bị mạng) mà còn cả hệ điều hành cũng như vùng chứa ứng dụng nơi ứng dụng của khách hàng chạy. Sau đây là ví dụ về một số sản phẩm PaaS phổ biến: AWS Elastic Beanstalk, Google App Engine, Force.com

Cổng – khi máy khách kết nối với máy chủ qua Internet, địa chỉ đích đến có 2 phần: (1) địa chỉ Giao thức Internet (IP) của máy chủ và (2) mã số cổng trên máy chủ đó mà một ứng dụng cụ thể sẽ phản hồi. Các giao thức thường gặp sẽ dùng những cổng riêng (ví dụ: HTTPS sử dụng 443) nhưng nếu muốn, nhà phát triển có thể dùng cổng tùy chỉnh cho việc liên lạc qua mạng.

R

REST API – một loại giao diện được áp dụng rộng rãi để xây dựng các dịch vụ có thể truy cập vào web, qua đó máy khách và máy chủ liên lạc với nhau bằng giao thức HTTP. Nhà phát triển trên nền tảng của Meta có thể lưu trữ REST API ở miền phụ (chẳng hạn như api.example.com) nơi ứng dụng di động của họ gửi và nhận Dữ liệu trên nền tảng.

S

Secure Shell (SSH) – một giao thức liên lạc hỗ trợ quản trị viên đăng nhập từ xa vào các máy chủ và chạy chương trình trên những máy chủ đó. Khác với các giao thức trước đây (chẳng hạn như Telnet), SSH được xem là an toàn do có biện pháp bảo vệ nội dung liên lạc giữa máy khách và máy chủ khỏi hành vi nghe trộm. SSH còn được gọi là Secure Socket Shell.

Secure Sockets Layer (SSL) – một phiên bản mã hóa khi truyền đã lỗi thời và không an toàn. Phiên bản bảo mật hiện đại có tên là Transport Layer Security (TLS).

Máy chủ – một máy tính cung cấp dịch vụ từ xa qua mạng. Trình duyệt và ứng dụng di động kết nối với máy chủ qua Internet.

Điện toán phi máy chủ – một mô hình điện toán đám mây, theo đó trung tâm lưu trữ đám mây quản lý cơ sở hạ tầng vật lý, hệ điều hành máy chủ và vùng chứa. Nhà phát triển chỉ chịu trách nhiệm về mã tùy chỉnh và các thư viện liên quan cùng với cấu hình đám mây.

Phía máy chủ – dữ liệu hoặc phép tính ở phía bên kia của kết nối mạng (tức là trên máy chủ). Ngược lại, dữ liệu hoặc phép tính trên thiết bị cục bộ như laptop hay thiết bị di động được gọi là phía máy khách.

Đăng nhập một lần (SSO) – một cơ chế sắp xếp mà trong đó, các ứng dụng dựa vào thư mục người dùng tập trung (tức là IdP) để xác thực người dùng. Ngoài việc tạo điều kiện để tổ chức quản lý tập trung tài khoản người dùng và quyền truy cập ứng dụng, SSO còn hữu ích với người dùng khi chỉ yêu cầu họ có một tập thông tin đăng nhập thay vì phải duy trì nhiều thông tin đăng nhập (ví dụ: tên người dùng và mật khẩu) cho từng ứng dụng khác nhau.

Bộ công cụ phát triển phần mềm (SDK) – một thành tố nền tảng về mã mà nhà phát triển có thể dùng để tinh giản quy trình làm việc cho nhu cầu nhất định. Ví dụ: Meta tạo cũng như duy trì các SDK giúp tinh giản quy trình làm việc của nhà phát triển iOS và Android với API Đồ thị. Tương tự như khi sử dụng thư viện, những nhà phát triển dùng SDK trong ứng dụng của họ cần phải cập nhật SDK theo thời gian.

Phần mềm dạng dịch vụ (SaaS) – hỗ trợ khách hàng dùng các ứng dụng dựa trên đám mây thông qua Internet. Khác với PaaS hoặc IaaS, khách hàng của ứng dụng SaaS không triển khai mã tùy chỉnh cũng như không có trách nhiệm đặt cấu hình, nâng cấp hay vá ứng dụng SaaS vì tất cả những việc này đều là trách nhiệm của nhà cung cấp phần mềm SaaS. Sau đây là ví dụ về một số sản phẩm SaaS phổ biến: Dopbox, MailChip, Salesforce, Slack.

Phân tích tĩnh – hãy xem thuật ngữ "Thử nghiệm tĩnh về khả năng bảo mật ứng dụng"

Thử nghiệm tĩnh về khả năng bảo mật ứng dụng (SAST) – một phương pháp tìm lỗ hổng bảo mật trong phần mềm bằng cách chạy công cụ chuyên biệt nhắm đến mã nguồn. Công cụ SAST sẽ xác định lỗ hổng bảo mật tiềm ẩn, chẳng hạn như những lỗ hổng bảo mật được nêu trong dự án OWASP Top 10. Sau đó, nhà phát triển sẽ chịu trách nhiệm xem xét thông tin phát hiện được, phân biệt lỗi thật và lỗi giả rồi khắc phục lỗ hổng bảo mật trong phần mềm đó. SAST có thể hữu ích do hỗ trợ nhà phát triển tìm thấy lỗ hổng bảo mật trước khi hoạt động sản xuất bị ảnh hưởng bởi những vấn đề này. Tuy nhiên, khác với kiểm thử thâm nhập, công cụ SAST sẽ không phát hiện ra lỗ hổng bảo mật liên quan đến cấu hình sản xuất của ứng dụng.

T

Mã hóa minh bạch dữ liệu – một phương thức mã hóa ở trạng thái nghỉ, thường áp dụng cho bộ nhớ cơ sở dữ liệu (tức là chính nội dung cơ sở dữ liệu và tệp nhật ký trong đó). Theo cơ chế sắp xếp này, phần mềm cơ sở dữ liệu sẽ quản lý khóa mã hóa và xử lý minh bạch hoạt động mã hóa (khi ghi) và hoạt động giải mã (khi đọc).

Transport Layer Security (TLS) – một giao thức mã hóa khi truyền dùng tính năng mã hóa để bảo vệ dữ liệu được truyền qua mạng khỏi những kẻ nghe trộm theo đường dẫn mạng. TLS là phiên bản bảo mật hiện đại của công nghệ lỗi thời trước đây mang tên SSL.

Xác thực 2 yếu tố (2FAC) – đồng nghĩa với Xác thực đa yếu tố. Kho lưu trữ – một hệ thống bí mật chuyên quản lý dữ liệu nhạy cảm, chẳng hạn như khóa mã hóa, mã truy cập và thông tin đăng nhập khác. Kho lưu trữ hỗ trợ kiểm soát chặt chẽ những ai truy cập được vào thông tin bí mật có trong đó, cũng như các dịch vụ bổ sung như lưu giữ nhật ký kiểm tra.

V

Máy ảo (VM) – rất giống với Vùng chứa ứng dụng, máy ảo sẽ chạy trong một trung tâm lưu trữ có tên là phần mềm giám sát máy ảo, còn Vùng chứa ứng dụng sẽ chạy trong công cụ vùng chứa ứng dụng. Điểm khác biệt cốt yếu là VM có hình ảnh Hệ điều hành, còn Vùng chứa ứng dụng thì không. Cả VM và Vùng chứa ứng dụng đều có (các) ứng dụng cũng như những yếu tố phụ thuộc (chẳng hạn như thư viện).

Đám mây riêng ảo (VPC) – thuật ngữ của AWS dùng để chỉ một tập hợp các nguồn lực đám mây tương tự mạng truyền thống tại trung tâm dữ liệu trong kỷ nguyên trước khi có đám mây.

Lỗ hổng bảo mật – một khiếm khuyết trong hệ thống hoặc ứng dụng có thể bị lợi dụng, ví dụ như khi người không có quyền đọc vẫn đọc được dữ liệu

Chương trình Công bố lỗ hổng bảo mật (VDP) – một hình thức mà qua đó, tổ chức có thể thu thập báo cáo về lỗ hổng bảo mật từ các nhà nghiên cứu (đôi khi được gọi là tin tặc mũ trắng) nhằm phát hiện và khắc phục lỗ hổng bảo mật trước khi kẻ xấu lợi dụng. Để đạt hiệu quả, VDP cần tập hợp các nhà nghiên cứu đang tích cực tìm lỗ hổng bảo mật, các nhà phân tích trong tổ chức chuyên xem xét và phân loại thông tin công bố sắp tới, cùng với các kỹ sư am hiểu về an ninh mạng có thể tạo và triển khai những bản khắc phục lỗ hổng bảo mật.

Quét lỗ hổng bảo mật – một biện pháp dùng phần mềm để tìm lỗ hổng bảo mật trong máy chủ, mạng và ứng dụng. So với kiểm thử thâm nhập, biện pháp quét lỗ hổng bảo mật tốn ít chi phí triển khai hơn nên có thể triển khai nhiều lần (ví dụ: hàng tháng hoặc hàng quý). Tuy nhiên, thông thường, quy trình kiểm thử thâm nhập sẽ tìm thấy lỗ hổng bảo mật bị bỏ sót khi quét lỗ hổng bảo mật vì những người kiểm thử thâm nhập lành nghề có kỹ năng và bản năng phân tích mà các biện pháp tự động cứng nhắc khó bắt chước được. Hãy xem thêm thuật ngữ "quét mạng".

W

Ứng dụng web – những chương trình chạy trong trình duyệt và chứa các nguồn lực như tài liệu HTML, mã JavaScript, video và tệp phương tiện khác cũng như CSS định kiểu. Ngược lại với việc cài đặt ứng dụng di động trên điện thoại di động sau khi tải về từ cửa hàng ứng dụng, mọi người chỉ cần tìm nạp ứng dụng web trên máy chủ từ xa bằng trình duyệt của họ (ví dụ: www.facebook.com) mà không cần thực hiện bước cài đặt.