Xây dựng một ứng dụng web tuân thủ quy định

Cân đối tài nguyên để bảo vệ các kiểu dữ liệu khác nhau

Chỉ có khoảng 25% trong hầu hết các kiểu dữ liệu của các tổ chức là nhạy cảm và điều này đặt ra câu hỏi: liệu bạn có nên thiết kế các ứng dụng đám mây của bạn để sử dụng 100% các tài nguyên bảo mật có sẵn nhằm bảo vệ tất cả các loại dữ liệu của bạn không? Phương pháp này rất tốn tài nguyên; nhưng còn có một cách khác. Trong bài này, tác giả gợi ý tạo ra ba loại cho mỗi kiểu dữ liệu do tổ chức của bạn sở hữu, sau đó sử dụng các loại đó để xác định cách áp dụng bảo mật cho mỗi kiểu dữ liệu khi bạn thiết kế ứng dụng sẽ dùng dữ liệu đó. Phương pháp này được gọi là Regulatory Compliant Cloud Computing (RC3 – Điện toán đám mây tuân thủ quy định)..

Arshad Noor, Trưởng ban công nghệ, StrongAuth Inc.

Arshad Noor là Trưởng ban công nghệ (CTO) của tập đoàn StrongAuth, một công ty có trụ sở tại Thung lũng Silicon đã tập trung vào các giải pháp quản lý-khóa doanh nghiệp trong thập kỷ qua. Ông có 25 năm kinh nghiệm trong lĩnh vực CNTT, trong đó có hơn 12 năm triển khai các cơ sở hạ tầng quản lý-khóa để bảo vệ dữ liệu nhạy cảm trong rất nhiều môi trường trọng yếu trên thế giới.



03 04 2013

Sự nổi lên của điện toán đám mây như một chiến lược triển khai thay thế khác cho các hệ thống CNTT đã tạo ra nhiều cơ hội, nhưng cũng thách thức các quan niệm truyền thống về bảo mật dữ liệu. Thực tế là các quy định bảo mật dữ liệu đang phát triển sức mạnh có hiệu quả lại để mặc cho các chuyên gia công nghệ thông tin bối rối về cách tận dụng lợi thế của điện toán đám mây trong khi chứng tỏ việc tuân thủ các quy định được thiết kế để bảo vệ thông tin nhạy cảm. (Ví dụ, TJX và Heartland Payment Systems (Các hệ thống thanh toán Heartland) đã cùng nhau trả số tiền hơn 220 triệu Đô la Mỹ là tiền phạt và tiền trả cho những vi phạm về các số thẻ tín dụng tương ứng là 94 triệu và 130 triệu trong năm 2007 và 2009. Đây là những vi phạm được tiết lộ công khai lớn nhất về các dữ liệu nhạy cảm của các hệ thống máy tính).

Có nhiều cách tiếp cận đến vấn đề này; các luận điểm thuận lợi để bắt đầu là:

  • Hoàn toàn không sử dụng điện toán đám mây.
  • Hoàn toàn chấp nhận điện toán đám mây.

Theo tôi, giải pháp tối ưu nằm đâu đó ở giữa: Với dữ liệu nhạy cảm cần được bảo mật và quản lý trong các vùng có kiểm soát trong khi dữ liệu không nhạy cảm nằm trong các đám mây. Điều này cho phép các công ty chứng tỏ tuân thủ các quy định bảo mật dữ liệu, trong khi vẫn sử dụng các đám mây riêng hay công cộng đến mức tối đa có thể.

Trong bài này, tôi sẽ mô tả làm thế nào để một kiểu kiến trúc ứng dụng web cụ thể tối ưu hóa các khoản đầu tư CNTT bằng cách sử dụng điện toán đám mây trong khi vẫn tuân thủ các quy định bảo mật dữ liệu.

Kiến trúc ứng dụng web truyền thống

Về mặt khái niệm, các ứng dụng web đơn giản. Trình duyệt — đại diện cho phía máy khách của một kết nối máy khách-máy chủ — hiển thị một biểu mẫu và cần có dữ liệu từ người dùng. Một chương trình phần mềm chạy trên một số máy chủ ứng dụng web đại diện cho máy chủ. Khi người dùng gửi đi biểu mẫu, chương trình máy chủ nhận và xử lý thông tin và trả về một phản hồi dựa vào kết quả của giao dịch. Sự tương tác này được hiển thị trong Hình 1.

Hình 1. Kiến trúc ứng dụng web tiêu chuẩn
Kiến trúc ứng dụng web tiêu chuẩn

Trong khi mô hình này có thể trở nên phức tạp tùy thuộc vào các ứng dụng thực hiện những nhiệm vụ nào, thì có một tính năng phổ biến trong các nhiệm vụ đó là: Biểu mẫu web phải nhận biết URL (Uniform Resource Locator - Trình định vị tài nguyên thống nhất) của máy chủ sao cho trình duyệt biết nơi để gửi dữ liệu mẫu tới khi người dùng gửi đi biểu mẫu để xử lý.

Đối với phần lớn ứng dụng, những người dùng thường tương tác với cùng một máy chủ trong suốt giao dịch. Tuy nhiên, tùy thuộc vào nhiều yếu tố, trình duyệt có thể được chuyển hướng đến các máy chủ khác nhau và vì thế, đến các URL khác nhau, với một số phần của giao dịch. Và tất nhiên, người dùng được bảo vệ khỏi những sự phức tạp của việc chuyển hướng ấy, cho phép họ thấy giao dịch liên tục. Trong hầu hết các tình huống, các sự chuyển hướng đều tới một miền giống nhau, ngay cả khi chúng tới các máy chủ khác nhau.

Trong một số ứng dụng thương mại điện tử, trình duyệt có thể được chuyển hướng đến một trang web của bộ xử lý thanh toán (payment processor), ở đó giao dịch thanh toán được xử lý và được chuyển hướng quay về trang web ban đầu để kết thúc giao dịch. Ưu điểm với trang web thương mại điện tử là ở chỗ chúng không phải xây dựng và duy trì cơ sở hạ tầng cho phần xử lý thanh toán giao dịch. Sự chuyển hướng này được thể hiện trong Hình 2.

Hình 2. Có sự chuyển hướng đến một bộ xử lý thanh toán
Có sự chuyển hướng đến một bộ xử lý thanh toán

Nhược điểm của chế độ hiện tại về các khoản đầu tư CNTT

Có nhiều nhược điểm về cách thực hiện các khoản đầu tư CNTT hiện nay. Giả sử hãy lấy một ứng dụng thương mại điện tử điển hình làm ví dụ, đó là một công ty phải chịu trách nhiệm về cái gì trong chế độ hiện tại về các khoản đầu tư CNTT:

  1. Công ty phải thu được tài nguyên vật lý — khả năng tính toán, lưu trữ và mạng — dùng cho tất cả các chức năng của ứng dụng:
    • Đăng ký khách hàng
    • Quản lý sản phẩm
    • Hàng tồn kho
    • Các giao dịch mua bán
    • Xử lý thanh toán
    • Hoàn thành giao dịch
    Và nhiều chức năng khác. Điều này thường dẫn đến gánh nặng tăng thêm cho một vài năm sau đó, đó là việc quản lý quá trình chuyển tiếp từ cơ sở hạ tầng đã cài đặt khi nó lỗi thời và không theo kịp các yêu cầu hiệu năng mong muốn sang cơ sở hạ tầng mới hơn.
  2. Công ty phải bảo đảm sự dư thừa về cơ sở hạ tầng điện toán để liên tục kinh doanh — điều này thường làm tăng gấp đôi khoản đầu tư cơ sở hạ tầng.
  3. Công ty phải giữ an toàn cho toàn bộ cơ sở hạ tầng. Vì hầu hết các trang web không phân biệt giữa dữ liệu nhạy cảm và dữ liệu không nhạy cảm, nên khung công tác bảo mật thường áp dụng cho tất cả các thành phần của cơ sở hạ tầng và dữ liệu. Điều này thể hiện một sự phân phối sai về tài nguyên do thông tin không nhạy cảm không cần có cùng một mức bảo vệ như thông tin nhạy cảm. (Trong vài năm qua, do PCI-DSS [Payment Card Industry Data Security Standard - Tiêu chuẩn bảo mật dữ liệu của Ngành thẻ thanh toán], nên các trang web đã tạo ra một sự khác biệt giữa một "vùng PCI" và "vùng không-PCI", "dữ liệu PCI " và "dữ liệu không-PCI". Vùng PCI và dữ liệu PCI (Ngành thẻ thanh toán) thường nhận được sự quan tâm và đầu tư nhiều hơn theo quan điểm bảo mật so với các đối tác không-PCI của mình. Trong khi có thể coi điều này là một dạng mẫu tối ưu hóa vì vùng không-PCI ở bên trong vành đai mạng của trang web, thì công ty sẽ vẫn phải chi tiêu nhiều tiền hơn để bảo vệ dữ liệu nếu ứng dụng được thiết kế theo kiến trúc được mô tả trong bài này).

Chế độ đầu tư này vẫn không thay đổi trong suốt 40 năm qua. Trong khi vốn đầu tư cơ bản cho mỗi khoản đầu tư đã giảm đáng kể từ những ngày có máy tính lớn (mainframe), thì một ứng dụng phải phục vụ hàng trăm ngàn người dùng vẫn cần có vốn đầu tư cơ bản khá lớn mặc dù đã có sẵn các máy chủ cho thuê và phần mềm nguồn mở.

Sự nổi lên của khoản đầu tư cho các thay đổi đám mây

Sự nổi lên của của công nghệ điện toán đám mây — đặc biệt là đám mây công cộng — thay đổi đáng kể cách có thể thực hiện các khoản đầu tư cho CNTT. Không còn cần thực hiện các khoản đầu tư lớn, mạo hiểm trả trước nữa và khấu hao các khoản đầu tư đó trong quá trình nhiều năm. Với tiền chi tiêu nhỏ hơn, các công ty có thể thiết lập chính xác các dịch vụ CNTT mà họ cần và chỉ trả tiền cho những gì họ sử dụng. Tác động kinh tế của sự thay đổi này không hề bị phóng đại; các doanh nghiệp mới có thể bước vào thị trường với ngân sách nhỏ hơn đáng kể.

Việc phân phối và việc quản lý các dịch vụ CNTT cũng sẽ quan trọng như sự thay đổi này, trách nhiệm về bảo vệ dữ liệu nhạy cảm không thể thuê ngoài được. Trong khi theo hợp đồng việc này có thể ủy quyền cho bên thứ ba, nên trách nhiệm về việc bảo đảm tuân thủ các quy định bảo mật vẫn còn đó với chủ sở hữu dữ liệu.

Như vậy, tôi nghĩ rằng các kiến trúc sư và các nhà thiết kế các ứng dụng web sẽ thấy mô hình được mô tả trong bài này có ích để đáp ứng các nghĩa vụ tuân thủ của họ trong khi vẫn tận dụng triệt để sức mạnh của điện toán đám mây.


Làm quen với Điện toán đám mây tuân thủ quy định (RC3)

Các giao dịch nghiệp vụ bao gồm một sự kết hợp của dữ liệu nhạy cảm và dữ liệu không nhạy cảm. Những gì được coi là nhạy cảm, cũng như tỷ lệ dữ liệu không nhạy cảm-so với-dữ liệu nhạy cảm, thay đổi tùy thuộc vào doanh nghiệp và kiểu giao dịch.

Nhưng giả sử có một sự phân phối thông thường, với phần lớn các doanh nghiệp thì tỷ lệ dữ liệu không nhạy cảm so với dữ liệu nhạy cảm sẽ khoảng 4:1. Vì thế, có thể cải thiện hiệu quả của các khoản đầu tư CNTT bằng cách tính toán, lưu trữ và quản lý dữ liệu nhạy cảm trong các vùng quy định bên trong một vành đai an toàn trong khi tất cả các dữ liệu không nhạy cảm có thể được tính toán, lưu trữ và quản lý trong các đám mây công cộng.

Tôi gọi kiến trúc này là Regulatory Compliant Cloud Computing (RC3): Một mô hình điện toán trong đó các giao dịch nghiệp vụ trải rộng trên các vùng quy định và các đám mây công cộng. Dữ liệu nhạy cảm được mã hóa, được phân chia thành các thẻ xác thực và được quản lý trong vùng quy định trong vành đai an toàn của một doanh nghiệp (hoặc một công ty gia công ủy thác) trong khi tất cả các dữ liệu không nhạy cảm lưu trú trong đám mây công cộng. Kiến trúc này được thể hiện trong Hình 3.

Hình 3. Mô hình kiến trúc RC3
Mô hình kiến trúc RC3

Tiếp theo, chúng tôi sẽ nghiên cứu việc phân loại dữ liệu trong kiến trúc RC3, rồi xem xét xem các giao dịch dữ liệu của các kịch bản ngành nghề khác nhau làm việc theo cấu trúc RC3 như thế nào.

Phân loại dữ liệu với RC3

Một điều kiện tiên quyết để xây dựng các ứng dụng RC3 là phân loại dữ liệu thành ba loại. Điều này là cần thiết sao cho có thể thiết kế các ứng dụng để xử lý dữ liệu cho phù hợp; để đơn giản hóa truyền thông giữa các đơn vị kinh doanh và nhân viên kỹ thuật, những người phát triển và hỗ trợ dịch vụ CNTT.

Hãy xem xét các cách phân loại RC3.

Lớp 1/C1: Gồm có dữ liệu nhạy cảm và dữ liệu quy định. Nếu tiết lộ những dữ liệu này cho công chúng sẽ dẫn đến việc bị phạt tiền, các vụ kiện tiềm ẩn và làm mất uy tín của tổ chức vi phạm. Các ví dụ về dữ liệu C1 là các số thẻ tín dụng, các số an sinh xã hội, các số tài khoản ngân hàng, dữ liệu khác của kiểu này.

Lớp 2/C2: Gồm có các dữ liệu nhạy cảm, nhưng không được quy định. Đây là dữ liệu không được quy định nhưng nếu tiết lộ cho công chúng sẽ gây bất lợi cho một công ty và/hoặc dẫn đến làm mất đi chút ít uy tín của tổ chức vi phạm. Các ví dụ về dữ liệu C2 là tiền lương nhân viên; doanh số bán hàng đối với các dòng sản phẩm cụ thể; tên, giới tính và tuổi của một khách hàng, v.v.

Lớp 3/C3: Gồm dữ liệu không nhạy cảm. Hay nói cách khác, bất kỳ dữ liệu nào không thuộc dữ liệu C1 hay C2. Ví dụ, các mô tả sản phẩm, các hình ảnh, v.v.

Cần lưu ý rằng việc phân loại dữ liệu có thể rất linh hoạt: Khi dữ liệu nhạy cảm được phân chia thành các thẻ xác thực theo hệ thống quản lý khóa và mã hóa (EKM) có thiết kế tốt, thì trên thực tế dữ liệu nhạy cảm được coi là dữ liệu không nhạy cảm. Trong trường hợp này, thậm chí dữ liệu C1/C2 có thể được phân loại như dữ liệu C3 sau khi các dữ liệu đó đã trải qua quá trình mã hóa và phân chia thành các thẻ xác thực.

Dựa trên các phân loại này, các công ty chọn dùng RC3 sẽ bảo đảm những điều sau đây:

  • Tất cả dữ liệu C1 sẽ được xử lý và được lưu trữ trong vùng quy định, trong một vành đai mạng an toàn. Các vùng này sẽ chứng tỏ chúng phù hợp với các quy định bảo mật dữ liệu thích hợp. Các thẻ xác thực dữ liệu C1 (dữ liệu nhạy cảm đã được mã hóa và thay thế bằng các thẻ xác thực) có thể được lưu trữ trong đám mây công cộng.
  • Tất cả dữ liệu C2 sẽ được xử lý an toàn, nhưng không nhất thiết ở các vùng quy định. Các thẻ xác thực dữ liệu C2 có thể được lưu trữ trong các đám mây công cộng.
  • Tất cả các dữ liệu C3 có thể được xử lý và lưu trữ trong đám mây công cộng.

Ứng dụng này phải được viết để xử lý việc phân tách dữ liệu này; nhưng kiến trúc ứng dụng web — đặc biệt là khả năng để chuyển hướng trình duyệt đến các máy chủ đích — tự thêm vào sự hỗ trợ mô hình này.

Các phần tiếp theo mô tả một vài ví dụ về các giao dịch trong các lĩnh vực ngành nghề khác nhau. Tuy nhiên, mô hình này có thể được áp dụng cho bất kỳ ngành nghề nào phải đối mặt với những thách thức tương tự.

Một giao dịch RC3 thương mại điện tử

Đối với ví dụ giao dịch RC3 thương mại điện tử, được mô tả ở mức cao, tôi đã mô tả kịch bản này bằng cách sử dụng mô hình ứng dụng Java™ nhưng bạn nên hiểu là mô hình này không hề dành riêng cho Java và có thể sao chép mô hình này dễ dàng trong .NET framework hoặc bằng cách sử dụng bất kỳ các ngôn ngữ kịch bản lệnh nào như PHP, Ruby, v.v. Ngoài ra, trong khi các ví dụ có thể cho thấy việc sử dụng Amazon Web Services (AWS - Các dịch vụ Web của Amazon)), thì đây chỉ là ví dụ để minh họa; mô hình này được sao chép dễ dàng trong bất kỳ cơ sở hạ tầng đám mây công cộng nào chẳng hạn như Azure, vCloud, IBM® SmartCloud, v.v.

Vùng quy định bao gồm một vùng bảo mật (DMZ) của công ty và một vùng an toàn (SECZ). Một máy chủ ứng dụng web nằm trong DMZ nhận các kết nối từ những người dùng trên Internet. Nó giao tiếp với một máy chủ cơ sở dữ liệu và một cơ sở hạ tầng quản lý khóa của doanh nghiệp (EKMI) trong SECZ. EKMI chịu trách nhiệm mã hóa dữ liệu, phân chia dữ liệu đầu vào thành các thẻ xác thực và quản lý khóa cho tất cả dữ liệu C1 và C2. Người ta dự kiến EKMI đã thực hiện tất cả các quyền kiểm soát cần thiết để đáp ứng các quy định bảo mật dữ liệu. Tất cả các giao tiếp đều qua TLS/SSL.

Vùng đám mây công cộng (PBZ - public cloud zone) gồm có một máy chủ ứng dụng web và một kho lưu trữ dữ liệu. Máy chủ ứng dụng web nhận các kết nối từ những người dùng trên Internet, cũng như các yêu cầu dịch vụ web từ máy chủ ứng dụng web trong DMZ của công ty. Tất cả các giao tiếp đều qua TLS/SSL. Các yêu cầu dịch vụ Web từ DMZ của công ty đến đám mây công cộng được bảo vệ thêm bằng SSL ClientAuth để xác thực lẫn nhau giữa các điểm cuối.

Kiểu giao dịch này thực hiện các bước sau.

  1. Người dùng đăng ký là một khách hàng trong vùng quy định và được cấp một mã định danh khách hàng duy nhất (CID), được coi là dữ liệu C3. Thông tin liên hệ tên của khách hàng được chọn làm dữ liệu C2 trong khi các thông tin chi tiết về đơn hàng của khách hàng được chọn làm dữ liệu C3. Dữ liệu C2 được mã hóa, phân chia thành các thẻ xác thực và được lưu trữ trong EKMI. Tất cả dữ liệu C3 được lưu trữ trong PBZ và được truyền qua liên kết SSL xác thực máy khách cùng với dữ liệu liên quan đến phiên làm việc cho giao dịch này. Xem Bước 1 trong Hình 4.
    Hình 4. Các bước trong một giao dịch thương mại điện tử RC3
    Các bước trong một giao dịch thương mại điện RC3
  2. Trình duyệt của người dùng được chuyển hướng đến PBZ vào lúc này, nơi hầu hết các giao dịch được xử lý bằng cách:
    1. Xem xét một danh sách các sản phẩm.
    2. Xác định giá và sự sẵn có của sản phẩm.
    3. Thêm các sản phẩm đã chọn vào giỏ hàng.
    4. Cung cấp các hướng dẫn vận chuyển.
    5. Bất kỳ dữ liệu liên quan đến không thanh toán khác nào.

    Các đầu trang yêu cầu mang theo các thẻ xác thực của phiên làm việc được máy chủ ứng dụng web trong DMZ gán cho; điều này cho phép dữ liệu giao dịch trong PBZ được liên kết với cùng một giao dịch trong vùng quy định. Xem Bước 2 trong Hình 4.

  3. Khi đã sẵn sàng thanh toán, trình duyệt của người dùng được chuyển hướng đến máy chủ DMZ của công ty, nơi người dùng gửi đi một thẻ tín dụng để thanh toán. Sau khi xác nhận giao dịch, dữ liệu nhạy cảm C1 được mã hóa, được phân chia thành các thẻ xác thực và được lưu trữ trong EKMI. Sau khi đã phân chia thành các thẻ xác thực, dữ liệu C3 được lưu trữ trong PBZ thông qua yêu cầu dịch vụ web xác thực khách hàng. Xem Bước 3 trong Hình 4.

    Một số lưu ý bảo mật về giao dịch thương mại điện tử:

    • Việc tuân thủ các quy định về bảo mật dữ liệu được chứng minh bằng thực tế là dữ liệu nhạy cảm và dữ liệu quy định được EKMI mã hóa và lưu trữ trong vùng an toàn.
    • PBZ không lưu trữ bất kỳ thông tin ủy quyền nào cho người dùng. Việc xác thực người dùng được thực hiện trong vùng quy định, một thẻ xác thực phiên làm việc hợp lệ được gán cho người dùng và trình duyệt của người dùng được chuyển hướng đến PBZ để tiếp tục xử lý.
    • Các giao tiếp giữa DMZ và PBZ chỉ theo một hướng, từ DMZ đến PBZ. PBZ không bao giờ giao tiếp với các máy chủ trong vùng quy định; nếu ứng dụng được thiết kế phù hợp, thì không cần làm như vậy. Điều này đảm bảo rằng bất kỳ sự thỏa hiệp nào trong PBZ không bao giờ lọt vào vùng quy định.
    • Các máy chủ từ vùng quy định giao tiếp với PBZ chỉ qua các dịch vụ web xác thực máy khách SSL. Điều này tránh được yêu cầu lưu trữ bất kỳ các thông tin xác thực nào trong PBZ. (Xác thực khách hàng SSL chỉ yêu cầu lưu trữ một chứng chỉ kỹ thuật số hợp lệ và tin cậy trên máy tính đích để xác thực một kết nối máy khách. Tuy nhiên, máy khách phải có một khóa riêng hợp lệ cho chứng chỉ kỹ thuật số đó và tham gia vào giao thức xác thực máy khách SSL).

Một giao dịch RC3 về chăm sóc sức khỏe

Ví dụ này, được mô tả ở một mức cao, tương tự như giao dịch thương mại điện tử, ngoại trừ giao dịch này tiến xa hơn bằng cách hiển thị cách có thể lưu trữ các BLOB lớn (các đối tượng nhị phân lớn) của dữ liệu không cấu trúc, chẳng hạn như một hình ảnh X-quang, trong PBZ trong khi vẫn chứng tỏ tuân thủ. Chúng tôi sẽ giả định rằng thông tin cơ sở về bệnh nhân đã được tạo ra trước giao dịch này.

Kiểu giao dịch này thực hiện các bước sau.

  1. Một kỹ thuật viên tại một phòng thí nghiệm X-quang tự xác thực mình với các máy chủ trong vùng quy định của một bệnh viện và thiết lập một phiên làm việc. Nếu cần tạo ra dữ liệu bệnh nhân mới, thì thực hiện việc này trong vùng quy định, nơi mỗi bệnh nhân được cấp một mã định danh bệnh nhân (PID). Một số yếu tố về dữ liệu nhân khẩu học của bệnh nhân được chọn làm dữ liệu C1/C2; như vậy, dữ liệu đó sẽ được EKMI mã hóa và phân chia thành các thẻ xác thực. Bệnh viện có sự lựa chọn hoặc giữ dữ liệu C1/C2 đã phân chia thành các thẻ xác thực trong vùng kiểm soát hoặc lưu trữ nó trong PBZ bằng cách sử dụng dịch vụ web một hướng an toàn vào đám mây. Xem Bước 1 trong Hình 5.
    Hình 5. Các bước trong một giao dịch chăm sóc sức khỏe RC3
    Các bước trong một giao dịch chăm sóc sức khỏa RC3
  2. Trình duyệt của kỹ thuật viên được chuyển hướng đến PBZ, nơi cô ta gửi đi các phần dữ liệu không nhạy cảm của giao dịch, chẳng hạn như:
    • Ngày và thời gian đến khám.
    • Yêu cầu mã định danh của bác sĩ và thời gian làm việc quy định của bác sĩ để kiểm tra.
    • Kỹ thuật viên của bệnh viện và các hành động được thực hiện.
    • Bất kỳ dữ liệu không nhạy cảm nào khác.

    Ứng dụng được thiết kế sao cho phần này của giao dịch không mang theo bất kỳ dữ liệu C1 hay C2 nào. Xem Bước 2 trong Hình 5.

  3. Khi sẵn sàng gửi đi hình ảnh X-quang và nhận xét của bác sĩ chẩn đoán hình ảnh, trình duyệt của kỹ thuật viên được chuyển hướng đến vùng quy định. Kỹ thuật viên tải lên hình ảnh X-quang và nhận xét của bác sĩ. Hình ảnh X-quang và nhận xét này có thể được ứng dụng web chuyển đổi thành một tài liệu XML. Tài liệu XML khá lớn này có chứa dữ liệu C1 cần phải được bảo vệ.

    Dữ liệu C1 nhận được trong máy chủ ứng dụng web DMZ và được gửi đến một công cụ mã hóa có khả năng mã hóa dữ liệu không cấu trúc lớn. Một khóa đối xứng được tạo ra và được sử dụng để mã hóa các nội dung tài liệu. Khóa đối xứng được lưu giữ trong EKMI trong khi ảnh X-quang và nhận xét đã mã hóa được lưu trữ trong PBZ thông qua một yêu cầu dịch vụ web an toàn. Xem Bước 3 trong Hình 5.

    Tất cả các lưu ý bảo mật áp dụng cho giao dịch thương mại điện tử cũng áp dụng cho giao dịch chăm sóc sức khỏe. Sự khác biệt duy nhất giữa hai giao dịch này là cần phải sử dụng một công cụ chuyên dụng có khả năng xử lý mã hóa và giải mã các BLOB lớn để thêm dữ liệu không cấu trúc, là ảnh X-quang, vào giao dịch chăm sóc sức khỏe.

Một giao dịch RC3 sản xuất

Ví dụ này cho thấy một kỹ sư trong một môi trường công nghiệp, gửi một tài liệu nhạy cảm là một kế hoạch chi tiết cùng với một hóa đơn về các vật liệu (BOM) cho một dây chuyền lắp ráp dùng cho mục đích sản xuất.

Kiểu giao dịch này thực hiện các bước sau.

  1. Một kỹ sư xác thực với các máy chủ trong vùng quy định và thiết lập một phiên làm việc. Sau đó, kỹ sư này được chuyển hướng đến PBZ. Một yêu cầu dịch vụ web chuyển tải một cách an toàn thông tin liên quan đến phiên làm việc từ SECZ đến PBZ.

    Trong vùng PBZ, kỹ sư này tạo ra một giao dịch mới chỉ chấp nhận gửi dữ liệu C3 vào đám mây. Giao dịch này được cấp một mã định danh giao dịch duy nhất và được trả về trình duyệt của kỹ sư đó dưới dạng các đầu trang đáp ứng của yêu cầu.

    Do giao dịch này dùng để tạo một phần mới của nhà máy sản xuất, nên phần công khai của giao dịch chấp nhận các thành phần không nhạy cảm của BOM. Xem Bước 1 trong Hình 6.

    Hình 6. Các bước trong một giao dịch sản xuất RC3
    Các bước trong một giao dịch sản xuất RC3
  2. Trình duyệt của kỹ sư được chuyển hướng đến SECZ, nơi gửi đi phần nhạy cảm của giao dịch. Thông tin đó như sau:
    • Kế hoạch chi tiết về đối tượng được sản xuất.
    • Các phần nhạy cảm của BOM.
    • Các hướng dẫn đặc biệt về lắp ráp, nếu có.
    • Bất kỳ dữ liệu nhạy cảm nào khác.

    Ứng dụng này được thiết kế sao cho phần giao dịch này mang dữ liệu C1 và C2 cần thiết để mã hóa và phân chia thành các thẻ xác thực trong SECZ. Kế hoạch chi tiết đã mã hóa được lưu trong PBZ do bây giờ nó không còn là dữ liệu nhạy cảm nữa. Xem Bước 2 trong Hình 6.

    Tất cả lưu ý bảo mật áp dụng cho các giao dịch trước cũng áp dụng cho giao dịch này.


Kết luận

Để kết thúc, với việc quản lý khóa mã hóa thích hợp, có thể sử dụng các đám mây công cộng để tính toán và lưu trữ dữ liệu nhạy cảm trong khi vẫn đáp ứng các yêu cầu tuân thủ các quy định về bảo mật dữ liệu. Công nghệ để tạo nên khả năng này hiện đang có sẵn; điều còn là để cho các ứng tận dụng lợi thế của những khả năng này — chủ yếu là, để thiết kế các ứng dụng đám mây sao cho chúng áp dụng mức tài nguyên bảo mật thích hợp cho các mức dữ liệu đã phân loại khác nhau để ứng dụng truy cập vào các mức dữ liệu đó để hoạt động.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Cloud computing, SOA và dịch vụ Web
ArticleID=863638
ArticleTitle=Xây dựng một ứng dụng web tuân thủ quy định
publish-date=04032013