Kết nối tới đám mây, Phần 3: Điều quản và bảo đảm an toàn cho đám mây

Bảo đảm an toàn cho ứng dụng HybridCloud

Trong phần ba và cũng là phần cuối cùng của loạt bài gồm ba phần về xây dựng ứng dụng đám mây lai, hãy xem xét việc điều quản và bảo đảm an toàn cho điện toán đám mây. Hãy xây dựng dựa trên ví dụ ứng dụng HybridCloud từ phần 2 bằng cách xem xét thêm các chính sách kiểm soát truy cập khi sử dụng dịch vụ hàng đợi đơn giản (Simple Queue Service -SQS) của Amazon. Hãy xem chi tiết cách ứng dụng HybridCloud xác thực chính nó tới dịch vụ điện toán đám mây và cách thêm lịch sử của hoạt động đăng nhập đến dịch vụ lưu trữ đơn giản (Simple Storage Service - S3) của Amazon. Cuối cùng, hãy xem cách Google Apps sử dụng OAuth và cách dịch vụ đám mây của Force.com yêu cầu làm sẵn kiểm tra để tránh các tấn công từ chối dịch vụ (Denial-of-Service -DoS) vô ý.

Mark O'Neill, Giám đốc công nghệ, Vordel

Mark O'Neill là giám đốc kỹ thuật (CTO) tại Vordel, một công ty mạng XML. Ông cũng là tác giả của cuốn sách “An ninh dịch vụ web” và là một trong những tác giả của cuốn sách "Củng cố an ninh mạng", cả hai cuốn được nhà xuất bản McGraw-Hill/Osborne Media phát hành. Mark chịu trách nhiệm giám sát lộ trình phát triển sản phẩm của Vordel và cũng tư vấn cho các chính phủ và công ty thuộc danh sách Global 2000 trên toàn thế giới trong chiến thuật và chiến lược để chọn dùng các công nghệ XML, dịch vụ Web và kiến trúc hướng dịch vụ của họ. Ông có bằng về toán học và tâm lý học tại trường Trinity College Dublin và trình độ đại học về lập trình mạng thần kinh tại đại học Oxford. Mark sống ở Boston, Massachusetts.



29 08 2012

Giới thiệu

Điều quản đám mây liên quan đến việc áp dụng các chính sách cho việc sử dụng các dịch vụ đám mây. Sẽ rất có ích khi suy nghĩ về điều quản đám mây thông qua cực đối lập của nó: đó là sự hỗn loạn kiểu “tự do cho mọi người” trong đó dịch vụ đám mây được sử dụng bởi các tổ chức mà không có bất kỳ giám sát tại chỗ nào. Để tránh sự hỗn loạn này, ta hãy áp dụng chính sách về sử dụng dịch vụ đám mây để kiểm soát sự rò rỉ thông tin cá nhân đến đám mây và kiểm soát việc lạm dụng các dịch vụ đám mây (xét cho cùng, đều phải trả tiền). Khi đã áp dụng điều quản và bảo đảm an ninh, điện toán đám mây có thể được sử dụng trong sự an toàn và tự tin.


Các bài học rút ra từ quản trị kiến trúc hướng dịch vụ

Điều quản là một từ đi cùng với việc chọn dùng kiến trúc hướng dịch vụ. Trong thế giới của kiến trúc hướng dịch vụ, nó được chia thành điều quản lúc thiết kế (xác định chính sách cho các dịch vụ Web) và điều quản chạy thực (thực tế là áp dụng những chính sách đó cho lưu lượng thời gian thực).

Các từ viết tắt thường được sử dụng

  • API (Application Programming Interface): Giao diện lập trình ứng dụng
  • DSA (Digital Signature Algorithm): Giải thuật ký số
  • IP (Internet protocol): Giao thức Internet
  • IT (Information technology): Công nghệ thông tin
  • REST (Representational State Transfer): Chuyển tải trạng thái đại diện
  • SOA (Service Oriented Architecture): Kiến trúc hướng dịch vụ
  • SSL (Secure Sockets Layer): Tầng ổ cắm bảo mật
  • URI (Uniform Resource Identifier): Mã định danh tài nguyên thống nhất
  • WSDL (Web Services Description Language): Ngôn ngữ mô tả dịch vụ web
  • XML (Extensible Markup Language): Ngôn ngữ đánh dấu có thể mở rộng được

Nền tảng điện toán đám mây, giống như các dịch vụ trong kiến trúc hướng dịch vụ, chủ yếu được truy cập bằng cách sử dụng API của dịch vụ web, và vì vậy có thể hy vọng rằng chúng có cùng những vấn đề như điều quản kiến trúc hướng dịch vụ. Ít nhất bạn có thể sử dụng lại các nguyên tắc ở phía sau điều quản kiến trúc hướng dịch vụ.

Điều quản kiến trúc hướng dịch vụ thường dựa vào sự hiện diện của đăng ký. Đây là điểm trung tâm mà người dùng có thể xem các dịch vụ trong kiến trúc hướng dịch vụ cũng như xem các chính sách áp dụng cho các dịch vụ. Chính sách dịch vụ web tiêu chuẩn, cũng như đặc tả đính kèm dịch vụ web bổ sung thêm, cho phép gán chính sách cho một dịch vụ trong kiến trúc hướng dịch vụ. Trong thực tế, sau đó dịch vụ chứa "con trỏ" đến chính sách của nó. Đăng ký quản lý mối quan hệ giữa các dịch vụ và các chính sách này.

Một chức năng quan trọng khác được các sản phẩm điều quản Kiến trúc hướng dịch vụ cung cấp là quản lý vòng đời của dịch vụ. Nó liên quan đến khả năng kiểm soát và theo vết các thay đổi của dịch vụ, và kiểm soát những ai có thể thay đổi dịch vụ. Một khi phương tiện này được lập nên, các tổ chức có thể xác định ai đã tạo ra dịch vụ, ai thay đổi nó và khi nào các thay đổi đó được thực hiện.

Có phải nếu đã có điều quản kiến trúc hướng dịch vụ thì có nghĩa là vấn đề điều quản đám mây đã được giải quyết hay không? Không hẳn như vậy. Các thông điệp được gửi đến và gửi đi từ các dịch vụ đám mây không phải là giao thức truy cập đối tượng đơn giản (SOAP) và các dịch vụ thường không được định nghĩa bởi WSDL, là hai chuẩn được sử dụng điều quản Kiến trúc hướng dịch vụ chung. Điều này có nghĩa là không dễ nhập khẩu các dịch vụ vào đăng ký của điều quản kiến trúc hướng dịch vụ. Các dịch vụ web được sử dụng bởi điện toán đám mây bỏ qua SOAP và WSDL và thay vào đó sử dụng các dịch vụ kiểu REST nhẹ, các dịch vụ này phổ biến hơn đối với các nhà phát triển do tính đơn giản tương đối của chúng.

Các máy chủ ảo là khía cạnh mới của điện toán đám mây, điều này làm cho điện toán đám mây khác với kiến trúc hướng dịch vụ. Cũng như việc sử dụng các dịch vụ web, điện toán đám mây cũng sử dụng các máy chủ ảo. Môi trường điện toán đám mây co dãn (Elastic Compute Cloud - EC2) của Amazon có thể được coi như là loại môi trường chủ chứa ảo hóa, không phải là tập hợp các dịch vụ. Do đó, điều quản EC2 của Amazon có thể được coi như là ví dụ về điều quản các máy chủ ảo. Đặc biệt việc triển khai máy ảo có thể dễ dàng kết thúc trong hỗn loạn, nếu như cuối cùng tổ chức có nhiều máy chủ ảo, các máy chủ ảo này có thể khác nhau đôi chút và không được làm tư liệu đầy đủ. Như nhiều người sử dụng VMware hoặc Citrix Xen đã nhận thức được, ngay cả đối với một người dùng cá nhân, để theo dõi các máy ảo là rất khó khăn. Hãy tưởng tượng các vấn đề tăng lên gấp bội như thế nào đối với các tổ chức, và tăng hơn nữa nếu các máy ảo được cư trú trong dịch vụ đám mây của bên thứ ba.

Tuy nhiên điều quản các máy ảo (Virtual Machine -VM) có một số trùng lặp với lợi ích của “điều quản vòng đời” trong điều quản kiến trúc hướng dịch vụ. Trong thế giới đám mây EC2 của Amazon, máy chủ ảo là một cá thể của ảnh máy của Amazon (Amazon Machine Image -AMI). Khả năng để áp đặt các quy tắc mà một người sử dụng nhất định nào đó có thể triển khai các AMI nhất định nào đó là rất quan trọng. Ở mức độ tốt hơn, khả năng kiểm soát những ai có thể khởi động lại máy ảo, những ai có thể thêm khả năng cho môi trường máy ảo hiện có và những ai có thể xóa các cá thể máy ảo hiện tại là rất quan trọng.

Vấn đề cuối, cụ thể là việc xóa các cá thể AMI Amazon là đặc biệt quan trọng vì các tổ chức phải trả tiền cho việc sử dụng những các thể này. Giá thanh toán dựa trên việc sử dụng (khi ảnh máy ở trong trạng thái đang chạy) và lưu lượng truy cập dữ liệu. Nếu không có hệ thống điều quản đám mây, thì các cá thể máy AMI chạy ngoài ý muốn có thể sinh sôi nảy nở và gây ra lãng phí. Tuy nhiên, điều trái ngược cũng đúng: không có giải pháp điều quản đám mây, rất có thể là các cá thể AMI hữu ích bị xóa nhầm. Quản lý vòng đời của các cá thể AMI tránh các vấn đề của các cá thể lừa đảo, cũng giống như điều quản kiến trúc hướng dịch vụ giải quyết các vấn đề của các dịch vụ lừa đảo có xu hướng sinh sôi nảy nở trong các tổ chức không có một khung công tác quản trị được thực hiện.


Một quá trình, không phải là một sản phẩm

Người ta thường nói rằng điều quản kiến trúc hướng dịch vụ là một quá trình, không phải là một sản phẩm. Điều quản đám mây cũng theo quy tắc này. Khả năng áp đặt các quy tắc điều quản phụ thuộc vào các nhà phát triển nhận thức được rằng khung công tác điều quản đã có. Ví dụ: Nếu đăng ký điều quản kiến trúc hướng dịch vụ được triển khai, thì nhà phát triển phải nhận thức rằng đây là nơi mà các dịch vụ web (đặc biệt là các định nghĩa về WSDL) phải được đăng ký. Nếu không có đăng ký này, thì các dịch vụ Web sẽ không được ai biết đến. Cũng như điều quản kiến trúc hướng dịch vụ, một cái gì đó tương tự xảy ra với điều quản đám mây nếu nhà phát triển không được yêu cầu đăng ký sử dụng dịch vụ điện toán đám mây của họ với chính tổ chức của họ.

Trong thế giới của điều quản kiến trúc hướng dịch vụ, bổ sung cho điều quản lúc thiết kế được cung cấp bởi đăng ký, còn có điều quản lúc chạy thực theo đó các quy tắc đã định cấu hình trong đăng ký buộc phải thi hành. Điểm thi hành này cho các dịch vụ thường có dạng một tác nhân nhúng hoặc trung gian mạng chẳng hạn như một cổng (gateway) XML.

Các công cụ điều quản kiến trúc hướng dịch vụ - đăng ký và điểm thực thi thời gian chạy thực chẳng hạn như tác nhân hoặc cổng XML - không có mặt trong thế giới điện toán đám mây. Điều này có nghĩa rằng không có điểm trung tâm cho người dùng dịch vụ điện toán đám mây để xem tất cả các dịch vụ và các chính sách liên quan. Và mặc dù chính sách được thi hành tại đầu kết nối phía điện toán đám mây (bởi chính nhà cung cấp dịch vụ đám mây), chúng không bị buộc phải thi hành tại phía khách. Đây là thách thức chính cho việc điều quản điện toán đám mây.


Các đám mây lừa đảo

Theo nhiều cách, điện toán đám mây giống như những ngày đầu của dịch vụ web. Các nhà phát triển tự mình quyết định sử dụng công nghệ mới này cho các dự án và sử dụng nó. Điều này không bị phát hiện bởi sự quản lý công nghệ thông tin của các công ty. Về sau chiếc ô điều quản được bổ sung thêm. Tại thời điểm này, hầu hết các tổ chức đang ở trong giai đoạn trước điều quản khi đến với điện toán đám mây. Việc nhà phát triển đưa ảnh AMI vào dự án không có gì bất thường, ngay cả những nguyên mẫu ban đầu cũng dính líu đến sử dụng tài khoản cá nhân Amazon và thẻ tín dụng của họ.


Có phải điều quản phía khách đã biến mất?

Một nhà cung cấp dịch vụ đám mây thường không phải thông báo trước thông tin thời gian dừng dịch vụ cho khách hàng. Tất nhiên khi việc ngừng dịch vụ xảy ra vì những lý do không lường trước được, thì nhà cung cấp dịch vụ đám mây không có trách nhiệm thông báo việc này cho người sử dụng các dịch vụ đám mây. Để theo dõi thời gian đáp ứng và khả năng sẵn dùng của dịch vụ đám mây, phải có một thành phần ở phía khách. Thành phần ở phía khách này (ví dụ cổng XML) theo dõi các kết nối tới nền tảng điện toán đám mây. Nếu kết nối chậm, thì cổng XML đưa cảnh báo, hoặc có hành động khắc phục lỗi chẳng hạn như sử dụng đáp ứng từ bộ nhớ sẵn (cache) của nó. Bằng cách sử dụng bộ nhớ sẵn theo cách này, các hậu quả của việc ngừng dịch vụ đám mây có thể được giảm nhẹ.

Cổng XML ở phía khách cũng có thể kiểm tra tỷ mỉ dữ liệu gửi lên đám mây để tránh rò rỉ dữ liệu cá nhân hoặc dữ liệu nhạy cảm của công ty. Các dữ liệu cũng có thể được mật mã hóa hoặc mật mã hóa một cách chọn lọc trước khi được gửi đến các nhà cung cấp đám mây. Ví dụ: Cổng XML có thể đảm bảo rằng dữ liệu chuyển đến nhà cung cấp dịch vụ điện toán đám mây đã được phi định danh, do vậy các thông tin cá nhân không thể gắn kết tới các dữ liệu.

Các cổng XML, chẳng hạn như cổng XML của Vordel phiên bản đám mây, lọc lưu lượng gửi đến các nền tảng điện toán đám mây, cũng như áp dụng các chính sách tới việc truy cập các dịch vụ đám mây. Bằng cách như vậy, các cổng XML cung cấp các con đường phía máy khách đến các dịch vụ đám mây.


Áp dụng kiểm soát cho ứng dụng HybridCloud

Trong phần 2 của loạt bài viết này, bạn đã bắt đầu tạo ra ứng dụng HybridCloud, ứng dụng này sử dụng dịch vụ web của Amazon. Đặt điều quản điện toán đám mây và bảo đảm an ninh trong phối cảnh chung, bạn sẽ thấy cách ứng dụng này được xác thực bởi các dịch vụ web của Amazon và cách áp dụng các chính sách để sử dụng nó.

Các khóa để kết nối tới Amazon

Ứng dụng HybridCloud sử dụng dịch vụ đám mây SQS của Amazon. SQS, giống như tất cả các dịch vụ web của Amazon (Amazon Web Services -AWS), yêu cầu sử dụng ID của khóa truy cập và khóa bí mật liên quan. Chúng ta đã thấy các khóa của Amazon đang được sử dụng trong mã Java của HybridCloud, đang mã hóa cứng các khóa vào ứng dụng đang sử dụng các đám mây SQS Amazon. Tuy nhiên, các khóa này là gì? Ta hãynghiên cứu chi tiết chúng.

RSA nghĩa là gì?

Các chữ cái "RSA" trong tên của thuật toán mật mã hóa bất đối xứng RSA có nghĩa là "Rivest, Shamir và Adleman," là những người đầu tiên viết thuật toán này.

Độc giả quen thuộc với cơ sở hạ tầng khóa công khai (Public Key Infrastructure -PKI) có thể giả định rằng hai khóa này trên thực tế là các khóa công khai và riêng tư được liên kết trong cặp khóa không đối xứng, giống như các khóa được sử dụng bởi các thuật toán RSA hoặc DSA cho chữ ký số và mật mã hóa. Tuy nhiên chúng không phải là các khóa công khai và riêng tư cổ điển. ID của khóa truy cập được sử dụng như là mã định danh, xác định bên truy cập các dịch vụ của AWS. Về khái niệm, nó tương tự như tên người dùng và nó có thể được gửi trong các yêu cầu không được mã hóa. Đúng vậy, khi dịch vụ đám mây S3 của Amazon được sử dụng cho việc lưu trữ trực tuyến, thì ID của khóa truy cập là một phần của URL. Nếu người dùng đã được gán ID của khóa truy cập là "12456789" thì sau đó URL được sử dụng để lấy ra tập tin được lưu trữ trong thùng chứa các tập tin của người sử dụng đó được lưu trữ trên Amazon S3 sẽ là: https://s3.amazonaws.com/123456789- bucketname/filekey.

Thùng chứa, theo định nghĩa của Amazon S3, chỉ đơn giản là thùng lưu trữ cho các tập tin. Để xác định không gian mà bạn sẽ cần trên S3 hãy tạo thùng chứa và đặt cho nó một cái tên duy nhất trên toàn hệ thống Amazon.

ID của khóa truy cập là có thể nhìn thấy rõ ràng trong URL, có nghĩa là nó cũng sẽ được lưu trữ trong các bản ghi nhật ký của cơ sở hạ tầng mạng, cơ sở này dẫn các yêu cầu đến thùng chứa của Amazon S3 để truy cập các tập tin. Vì vậy, bất kỳ bộ định tuyến hoặc máy chủ ủy quyền (proxy) nào cũng sẽ có quyền truy cập đến ID của khóa truy cập. Nó không hữu ích cho việc xác thực, vì nó rất dễ bị phát hiện. Nó thực sự chỉ để định danh chứ không phải để xác thực.

Khóa truy cập bí mật là khóa được sử dụng để xác thực. Tuy nhiên, khóa này không được phía khách gửi đến các dịch vụ của AWS. Thay vào đó, nó được sử dụng để tạo ra một dạng chữ ký kỹ thuật số được sử dụng để cung cấp bằng chứng về sở hữu khóa truy cập bí mật. Bằng chứng về sở hữu này tương tự như cách giao thức bắt tay SSL sử dụng mật mã hóa để chứng minh rằng khách hàng thực tế là người giữ khóa riêng, mà không gửi đi chính khóa đó. Việc khách hàng có thể sử dụng khóa chỉ ra rằng khóa nằm dưới sự kiểm soát của chính khách hàng đó.

Trong trường hợp của cặp khóa công khai và riêng tư của PKI, có một quan hệ toán học giữa các khóa đang bàn đến. Dữ liệu được mật mã hóa bằng cách sử dụng khóa riêng có thể được giải mã bằng cách sử dụng khóa công khai tương ứng. Đây là cơ sở cho chữ ký kỹ thuật số dựa trên PKI. Chỉ có những người giữ khóa mới có thể tạo ra chữ ký, trong khi bất cứ ai có quyền truy cập vào khóa công khai (thường được lấy ra từ giấy chứng nhận X.509) đều có thể xác nhận chữ ký.

Khóa truy cập bí mật trong mô hình dịch vụ web của Amazon không có các đặc tính này. Thay vào đó bạn có thể nghĩ về nó như điều bí mật được chia sẻ giữa Amazon.com và nhà phát triển sử dụng các tài nguyên AWS chẳng hạn như các dịch vụ đám mây. Nó không được chia sẻ với người khác để có thể sử dụng nó để truy cập vào dịch vụ điện toán đám mây của Amazon. Bởi vì việc sử dụng các dịch vụ điện toán đám mây được tính vào hoá đơn của nhà phát triển, điều sống còn là khóa truy cập bí mật không được rơi vào tay kẻ xấu, nếu không, có thể bị mất một khoản tiền lớn. Nếu bạn nghi ngờ rằng bên thứ ba đã truy cập được khóa truy cập bí mật, bạn có thể tạo ra khóa truy cập bí mật mới trực tuyến.

Trong ứng dụng HybridCloud của bạn, các khóa đã được mã hóa cứng vào trong chính ứng dụng. Tuy nhiên, trừ phi bạn sử dụng một trình giấu mã nguồn (obfuscator) Java, kẻ tấn công có thể dịch đảo ngược ứng dụng, do đó sẽ phát hiện ra các khóa. Đây là lý do xác đáng để sử dụng trình giấu mã nguồn (obfuscator) Java (xem phần Tài nguyên).

Chính sách cho ứng dụng HybridCloud

Trong phần 2 của loạt bài viết này, bạn đã thấy ứng dụng HybridCloud gửi dữ liệu X quang đến SQS của Amazon. Vì hình ảnh X quang rõ ràng là dữ liệu y tế riêng tư, nên dữ liệu này được gửi tới dịch vụ SQS Amazon phải được kiểm tra tỷ mỉ đối với dữ liệu riêng tư tại phía khách. Một khi dữ liệu đến được SQS Amazon thì đã quá muộn. Đây là một lý do khác để sử dụng cổng cục bộ để kết nối đến tài nguyên của điện toán đám mây.

Một vấn đề khác cần xem xét về bảo đảm an toàn cho ứng dụng HybridCloud là khóa truy cập vào các dịch vụ Amazon SQS sao cho chỉ những khách hàng đáng tin cậy mới có thể truy cập dịch vụ. Điều này đạt được bằng cách sử dụng chính sách SQS của Amazon. Chính sách SQS của Amazon được định nghĩa bằng ký pháp đối tượng của JavaScript (JavaScript Object Notation -JSON).

Hãy nghiên cứu một số chính sách của SQS Amazon mà bạn có thể áp dụng cho ứng dụng HybridCloud của bạn (để biết các chi tiết và mã nguồn của ứng dụng, xem phần 2 của loạt bài viết này).

Đầu tiên, chính sách này xác định rằng chỉ có nhà phát triển với số tài khoản của dịch vụ web của Amazon là 1234567890 mới có thể truy cập vào hàng đợi, hàng đợi này được sở hữu bởi nhà phát triển với URI tài nguyên là /987654321/queue1 (xem liệt kê 1).

Liệt kê 1. Nghiên cứu chính sách của SQS Amazon
{ "Version": "2008-10-17", 
  "Id": 12345678901234567890 
  "Statement": {
       "Sid":"Queue1_SendMessage", 
       "Effect": "Allow", 
       "Principal": { 
          "AWS": "1234567890" },
       "Action": "SQS:SendMessage", 
       "Resource": "/987654321/queue1" 
   } 
}

Bây giờ ta nghiên cứu cụ thể chính sách. Đầu tiên bạn thấy thông tin về phiên bản. Tại thời điểm này, giá trị hợp lệ duy nhất cho trường đó là 2008-10-17. Tiếp theo, bạn sẽ thấy ID cho quy tắc của bạn. Nó phải là một mã định danh duy nhất toàn cục trong các dịch vụ web của Amazon. Statement (Câu lệnh) là chính sách hiện tại. Trong đó, bạn có thể nhìn thấy Resource (tài nguyên) là hàng đợi SQS của Amazon. Bạn đang xác định rằng một Principal (Người thuê) cụ thể (trong trường hợp này là người dùng AWS cụ thể) có thể truy cập vào hàng đợi cụ thể và chỉ có người thuê ấy là có thể truy cập vào hàng đợi.

Bạn cũng có thể thiết lập các chính sách kiểm soát truy cập vào hàng đợi SQS của chúng tôi dựa vào ngày tháng, thời gian và địa chỉ IP nguồn, như trong liệt kê 2.

Liệt kê 2. Thiết lập chính sách kiểm soát truy cập vào hàng đợi SQS
"Condition" : [{ 
  "DateGreaterThan" : { "AWS:CurrentTime" : "2009-04-10T09:00:00Z" } 
  "DateLessThan": { "AWS:CurrentTime" : "2009-04-10T17:30:00Z" } 
  "IpAddress" : { "AWS:SourceIp" : ["4.3.2.1/24"] } 
}]

Trong trường hợp này, chính sách được mã hóa cho thấy khách hàng chỉ có thể truy cập vào hàng đợi từ 9 sáng đến 17 giờ 30 ngày 10 tháng Tư 2009 và từ một dải địa chỉ IP cụ thể.

Bạn có thể sử dụng các hàm AddPermission và RemovePermission để thiết lập và loại bỏ từng quyền truy cập riêng biệt cho mỗi hàng đợi.

Tất nhiên các chính sách cho SQS Amazon hoạt động tại các nhà cung cấp dịch vụ điện toán đám mây. Tuy nhiên nếu dữ liệu được gửi đến các nhà cung cấp đám mây cần phải được mật mã hóa hoặc kiểm tra tỷ mỉ trước khi gửi, thì thiết bị cổng XML phía khách là một công cụ lý tưởng cho công việc này.

Bây giờ bạn biết cách khóa truy cập dịch vụ SQS của Amazon cho ứng dụng HybridCloud của bạn, ta hãy xem một chút các giải pháp bảo đảm an toàn điện toán đám mây từ Amazon, Google và Salesforce.


Amazon S3

S3 (Simple Storage Service – Dịch vụ lưu trữ đơn giản) của Amazon là dịch vụ đám mây được sử dụng để lưu trữ trực tuyến. Nó được sử dụng như là thiết bị lưu trữ phía sau của các trang web chẳng hạn như trang web chia sẻ hình ảnh SmugMug (xem Tài nguyên để có liên kết). Tất nhiên nó cũng có thể được sử dụng cho các dữ liệu riêng tư của công ty. Dữ liệu mà bạn lưu trữ trong S3 của Amazon có thể nhạy cảm, tùy thuộc vào bối cảnh. Nếu dữ liệu của bạn là riêng tư, thì phải mật mã hóa dữ liệu bằng cách sử dụng cổng XML trước khi bạn gửi nó đến dịch vụ SQS của Amazon. Ngoài ra, hãy theo dõi cách dữ liệu được truy cập từ SQS của Amazon. Bên cạnh các vấn đề riêng tư, bạn sẽ muốn theo dõi việc sử dụng S3 đơn giản bởi vì việc sử dụng này phải trả tiền. Không ai muốn bất ngờ khi phải trả một món tiền lớn mà không có sự kiểm tra đầy đủ việc sử dụng dẫn đến phải trả món tiền lớn đó. Vì tất cả những lý do này, điều quan trọng là phải bật chế độ ghi nhật ký các dịch vụ của S3 của Amazon.

Cách đơn giản để bật chế độ ghi nhật ký thùng chứa S3 của Amazon là sử dụng các ứng dụng của trình thám hiểm Cloudberry (Cloudberry Explorer) để bật chế độ ghi nhật ký cho cá thể S3 (xem phần Tài nguyên để biết thêm thông tin). Trình thám hiểm Cloudberry cung cấp mặt trước của giao diện đồ họa người dùng (GUI) cho S3 của Amazon. Trong trình thám hiểm Cloudberry, bạn chỉ cần chọn thùng chứa và nhấp vào nút Logging (Ghi nhật ký) trên thanh công cụ. Bây giờ bạn đánh dấu chọn hộp Use logging (sử dụng ghi nhật ký). Chọn thùng chứa sẽ chứa các tập tin nhật ký của bạn bằng cách chọn nó từ danh sách thả xuống. Trong ví dụ của chúng ta, nó là cloudberry.log. Các bản ghi nhật ký được thực sự ghi vào dịch vụ đám mây của Amazon. Các tệp tin nhật ký phải được ghi vào thùng chứa trong cùng một vị trí địa lý (có nghĩa là ứng dụng ở nước Mỹ phải ghi vào bản ghi nhật ký ở Mỹ). Các tệp tin nhật ký sẽ tính thêm vào hóa đơn hàng tháng bởi vì chúng sử dụng lưu trữ S3 của Amazon. Tuy nhiên, đây chỉ là chi phí nhỏ (theo nghĩa đen) phải trả để có sự kiểm soát theo vết người dùng đã truy cập dịch vụ lưu trữ S3 của Amazon của bạn.


Google Apps

Google cung cấp công cụ gọi là bộ kết nối các dữ liệu an toàn (SDC) của Google để kết nối các ứng dụng Java phía khách tới dịch vụ đám mây của Google Apps. Nó cung cấp liên kết được mật mã hóa giữa mạng cục bộ và Google Apps. Điều này chủ yếu được sử dụng cho các ứng dụng của Google Apps (mà Google là chủ chứa) để kết nối tới mạng cục bộ. Nó được xây dựng để đảm bảo rằng chỉ có Google Apps có thể kết nối qua kết nối này. Ngoài ra, nó cung cấp các bộ lọc để giới hạn các tiện ích nào của Google Apps có thể truy cập hệ thống nội bộ nào, rất giống như quy tắc bức tường lửa, nhưng ở mức ứng dụng. Ngoài việc kiểm soát ứng dụng nào có thể được truy cập, bạn có thể thêm kiểm soát cấp độ người dùng. Điều này cho phép các tổ chức kiểm soát những ai truy cập những dịch vụ nào của Google Apps.

Khung công tác xác định danh tính cho SDS của Google Apps sử dụng OAuth. Ví dụ: các dịch vụ được cư trú trên Google Apps có thể tự xác định danh tính cho chúng (và cho người dùng của chúng) đối với các ứng dụng cục bộ bằng cách sử dụng OAuth. Hiện nay OAuth không được triển khai rộng rãi. Tuy nhiên, sự phê chuẩn OAuth của Amazon có thể thay đổi tình hình đó.


Force.com: Bảo vệ và "vừa làm vừa kiểm tra"

Như bạn đã thấy trong phần 1 của loạt bài viết này, dịch vụ đám mây Force.com của SalesForce sử dụng ngôn ngữ lập trình được gọi là Apex. Force.com quy định rằng mã Apex đang cư trú trên nền tảng đám mây của họ bao gồm các asserts (khẳng định) để đảm bảo rằng mã đó đang hành xử đúng yêu cầu. Và điều này phải bao gồm ít nhất 75% và cao nhất là 100% các lớp Apex của nhà phát triển. Biện pháp này đã được thực hiện để tránh các cuộc tấn công từ chối dịch vụ (Denial-of-Service -DoS) vô ý vào toàn thể hệ thống. Ví dụ: Mã có thể đi vào một vòng lặp vô hạn, hoặc sử dụng tài nguyên quá mức, phải được bọc trong mã kiểm thử, sẽ phát hiện các tình huống như vậy. Như là một biện pháp tự vệ bổ sung, Force.com cũng áp đặt các giới hạn (được gọi là các tham số điều quản) để ép buộc các quy tắc với những số đo như độ sâu của ngăn xếp và kích thước chuỗi ký tự.

Mặc dù các nhà cung cấp dịch vụ đám mây khác không nêu quy định phải kiểm tra giống như Force.com, nhưng làm theo khuyến nghị của họ vẫn là một ý tưởng tốt, ngay cả khi bạn không sử dụng Force.com là nền tảng đám mây của bạn. Cùng với việc bảo vệ chống lại các cuộc tấn công từ chối dịch vụ, bạn cũng đảm bảo rằng bạn không bị bất ngờ khi nhận được các hóa đơn sử dụng không ngờ tới mà các nhà cung cấp dịch vụ đám mây gửi đến.


Tóm tắt

Một số sáng kiến chẳng hạn như Liên minh bảo đảm an toàn cho đám mây đã thành lập để giải quyết vấn đề bảo đảm an toàn cho điện toán đám mây. Tại thời điểm này, các nhà cung cấp dịch vụ như Amazon, Google và Force.com đang dẫn đầu ở mức nhà cung cấp dịch vụ. Tuy nhiên, không phải tất cả các nhà cung cấp đó đều thuyết phục: Ủy ban Thương mại liên bang đã được yêu cầu điều tra các rủi ro liên quan đến điện toán đám mây vì những vấn đề quản lý dữ liệu đã được biết đến. Khi đã xây dựng được ý thức về điều quản và bảo đảm an toàn điện toán đám mây, ta có thể mong đợi rằng các sản phẩm chào hàng về điều quản và bảo đảm an toàn điện toán đám mây sẽ phát triển hơn nữa.

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=SOA và dịch vụ Web
ArticleID=832310
ArticleTitle=Kết nối tới đám mây, Phần 3: Điều quản và bảo đảm an toàn cho đám mây
publish-date=08292012