2/10/12

Thiết kế bảo mật cho ứng dụng di động và máy tính để bàn Web 2.0

Tóm tắt:  Hầu hết các cuộc tấn công cố ý đều được nhằm vào các ứng dụng web. Các cuộc tấn công này tập trung vào các lỗ hổng phổ biến nhất, gồm cross-site scripting (tạo kịch bản lệnh giữa các trang web), SQL injection (chèn lệnh SQL), giả mạo tham số, đầu độc cookie và rò rỉ thông tin. Các hàng rào phòng thủ vòng ngoài truyền thống, như các tường lửa và các hệ thống phát hiện xâm nhập, sẽ không ngăn chặn được kiểu tấn công này, bởi vì các kiểu tấn công này khai thác các lỗ hổng chương trình. Bài này mô tả các lỗ hổng phổ biến nhất và các biện pháp đối phó có thể và giải thích giá trị của việc quét bảo mật tự động hóa trong quá trình phát triển để tạo ra các ứng dụng an toàn.


Các biện pháp kiểm soát truy cập, các tường lửa, các hệ thống phát hiện xâm nhập và các hệ thống phòng chống xâm nhập là một phần không thể thiếu được của việc bảo mật ứng dụng nhờ đặt ra phòng thủ vòng ngoài. Tuy nhiên rút cục thì các cơ chế này không ngăn chặn các cuộc tấn công ứng dụng web. Vì các ứng dụng này dựa trên web, việc truyền thông với các ứng dụng do người dùng web thực hiện cho phép các cuộc tấn công trực tiếp phá vỡ các hàng rào bảo vệ an ninh vòng ngoài đã thiết lập. Những kẻ tấn công nhận thức được điều này và nên các cuộc tấn công ứng dụng web trực tiếp hầu hết là các cuộc tấn công cố ý.
Để cân bằng giữa các yếu tố, các nhà phát triển ứng dụng phải hiểu rõ các chiến lược bảo vệ chống lại các cuộc tấn công. Họ cũng phải xem xét giải quyết một số các yếu tố góp phần vào một số các cuộc tấn công:
  • Hầu hết các nhà phát triển ứng dụng web không phải là chuyên gia bảo mật và có thể không biết về hầu hết các lỗ hổng.
  • Nhiều người không nhận thức được các biện pháp bảo mật tốt nhất để phát triển ứng dụng web.
  • Chức năng thường được ưu tiên cụ thể còn các lo lắng về bảo mật được giải quyết sau như là các giải pháp bổ sung.
  • Môi trường triển khai các ứng dụng web có tốc độ thay đổi cao, bao gồm các bản cập nhật cho chính mã ứng dụng đó cũng như cơ sở hạ tầng. Một số các thay đổi này không được kiểm tra và đánh giá hoặc không được các chuyên gia bảo mật thích hợp thử nghiệm.
Những yếu tố sau dẫn đến các bước mà mỗi nhà phát triển ứng dụng có thể dùng đến để viết mã tốt hơn.
  1. Được đào tạo.
  2. Tìm kiếm các mẫu đã thiết lập.
  3. Tích hợp thử nghiệm trong kế hoạch phát triển của bạn.
  4. Báo cáo sớm các lỗi.
Bài này góp phần đào tạo cho các nhà phát triển và các nhà triển khai về một số các lỗ hổng của ứng dụng web phổ biến nhất có ảnh hưởng đến các ứng dụng Web 2.0. Nó cũng giới thiệu về các vấn đề bảo mật đáng lưu ý cho thiết bị di động.
Các lỗ hổng web phổ biến
Các ứng dụng web di động dễ bị tấn công với nhiều lỗ hổng tương tự thường gắn với các ứng dụng web của máy tính để bàn. 10 dự án hàng đầu trên trang web Dự án bảo mật ứng dụng của Web mở (OWASP- Open Web Application Security Project) là một tài nguyên để tìm hiểu thêm về các lỗ hổng và các biện pháp đối phó (xem phần Tài nguyên để biết một liên kết).
Các phần nhỏ tiếp theo mô tả một số các lỗ hổng hàng đầu mà các nhà phát triển phải hiểu rõ.
Trong cuộc tấn công phổ biến này, mã độc được nhiễm vào một trang web xác thực khác. Nếu đầu vào của một yêu cầu HTTP có thể làm cho nó trở thành mã HTML kết quả của một trang web, thì trang đó sẽ được mở ra cho cuộc tấn công này.
Ví dụ, một dịch vụ chấp nhận một tham số có tên là image (hình ảnh) để lấy ra một hình ảnh từ hệ thống tệp để thực hiện một số xử lý::
http://somedomain/myImageProcessor?image=myimage.jpg

Một kẻ tấn công có thể cố gắng khai thác ứng dụng này bằng cách chèn mã JavaScript vào tham số image . Mục đích là để khai thác xử lý lỗi không hoạt động. Nếu một thông báo lỗi có thể được tạo ra bao gồm cả kịch bản lệnh độc hại, thì kẻ tấn công có thể lắp vào phía sau nó:
http://somedomain/myImageProcessor?image=myimage.jpg<script>...malicious code ...</script>

Nếu thông báo lỗi trả về các nội dung của tham số hình ảnh mà không lọc, mã kèm theo bên trong của các thẻ <script> sẽ thực thi. Kịch bản lệnh này có thể có khả năng truy cập vào các cookie cục bộ với trang web bị tấn công và thậm chí thay đổi nội dung của trang đã hiển thị. Có thể khai thác lỗ hổng này bằng cách gửi các liên kết bị nhiễm độc bằng email hoặc đưa chúng vào các trang web độc hại.
Khái niệm này được thể hiện trên trang web Altoro Mutual, là trang web trình diễn với các khả năng quét-lỗ hổng của ứng dụng của Ấn bản tiêu chuẩn Rational AppScan của IBM (IBM® Rational® AppScan® Standard Edition) (xem liên kết trong phần Tài nguyên).

Hình 1. Trang web trình diễn Quét ứng dụng Altoro Mutual (Altoro Mutual AppScan)
Tính năng tìm kiếm của Altoro Mutual

Như Hình 2 cho thấy, việc tìm kiếm từ "pineapples" (những quả dứa) cho bạn thấy rằng các từ tìm kiếm được hiển thị cho người sử dụng với các kết quả, bất kể là có kết quả hay không.

Hình 2. Các kết quả tìm kiếm luôn hiển thị từ tìm kiếm
Các kết quả tìm kiếm: Không tìm thấy kết quả nào với từ truy vấn pineapples

Kết quả này là một đầu mối mà ứng dụng dễ bị tấn công cross-site scripting. Hình 3 cho thấy kết quả khi từ tìm kiếm script <script>alert('attack')</script> được nhập vào làm một từ tìm kiếm. Mã của kịch bản lệnh được trả về trong kết quả tìm kiếm, mã này được thực thi và hiển thị một cửa sổ cảnh báo.

Hình 3. Nhập "JavaScript" làm một từ tìm kiếm dẫn đến việc thực thi mã JavaScript
Các kết quả tìm kiếm vẫn nói không có kết quả nào, nhưng cũng nói từ attack!

Các biện pháp đối phó
Để ngăn chặn cross-site scripting (XSS):
  • Không hiển thị đầu vào không đáng tin cho người dùng.
  • Áp dụng các bước để dọn sạch đầu vào và đầu ra nhằm loại bỏ mã độc hại, ví dụ như lọc hoặc danh sách trắng (định nghĩa những gì đầu vào được phép và không cho phép bất cứ điều gì khác).
  • Mã hóa đầu ra để ngăn chặn thực thi trình duyệt.
Đối với Altoro Mutual, một sự sửa lỗi đơn giản sẽ không trả về tìm kiếm.
Để thảo luận chi tiết hơn về cross-site scripting và phòng chống, hãy đọc bài có tên là "IBM Rational AppScan: Cross-site scripting explained," trên developerWorks® cũng như trang kiến thức Open Web Application Security Project (OWASP) về cross-site scripting (xem phần Tài nguyên để có các liên kết)
Kiểu tấn công này cũng tập trung vào việc khai thác các điểm yếu trong các yêu cầu và nhằm mục đích chèn một mục SQL vào các trường đầu vào của một ứng dụng web. Một kẻ tấn công, có thể chèn các truy vấn làm một phần của một trường đầu vào, có thể vượt qua các cơ chế xác thực của một trang web và truy cập tới cơ sở dữ liệu. Kiểu tấn công này là một kiểu được khai thác nhiều nhất, cùng với cross-site scripting.
Ví dụ này cho thấy một thủ tục đăng nhập được xây dựng kém bị khai thác như thế nào bằng SQL injection:
Một ứng dụng web sẽ nhắc đưa vào một tên người dùng và mật khẩu để đăng nhập và câu lệnh SQL được xây dựng theo cách sau:
String query = "SELECT * FROM users WHERE user ='"username+"' AND password ='"passwd"'";

Các biến username (tên người dùng) và password (Mật khẩu) không được dọn dẹp theo bất kỳ cách nào và được gán cho các giá trị do người dùng nhập vào ứng dụng. Điều này cho phép người dùng xấu nhập vào một cái gì đó như dưới đây làm tên người dùng: 
anything' OR 1=1 --

Mật khẩu có thể là bất cứ cái gì. Trong trường hợp này, giả sử nó là một dấu hoa thị: *.
Khi mã thay thế các biến username và password cho đầu vào này, truy vấn được dựng lên là:
SELECT * FROM users WHERE username ='anything' OR 1=1 -- AND password ='*'

Câu lệnh này ghi chú yêu cầu mật khẩu và chèn điều kiện 1=1, đó là luôn luôn đúng. Kẻ tấn công sẽ được xác nhận hợp lệ như một người dùng hợp lệ mặc dù các chứng nhận vẫn chưa được cung cấp.
Kiểu tấn công này được ứng dụng web Altoro Mutual thể hiện (xem Hình 4). Hãy chuyển đến trang đăng nhập và nhập một tên người dùng là anything' OR 1=1 -- và bất kỳ ký tự nào làm một mật khẩu cấp quyền truy cập vào ứng dụng đó như là một quản trị viên (Hình 5). Tài khoản này có quyền xử lý các tài khoản người dùng khác.

Hình 4. Một cố gắng để đăng nhập bằng một tên người dùng tùy ý và đoạn mã SQL làm một mật khẩu
Mã SQL được nhập làm tên người dùng


Hình 5. Kẻ tấn công đăng nhập với quyền quản trị viên sau khi thực hiện một cuộc tấn công SQL injection
SQL injection cung cấp quyền truy cập của quản trị viên cho kẻ tấn công

Cũng giống như cross-site scripting, cuộc tấn công này là kết quả của việc xác nhận hợp lệ và dọn dẹp đầu vào kém hoặc không có sẵn.
Các biện pháp đối phó
Để ngăn chặn cuộc tấn công này:
  • Xử lý tất cả đầu vào từ người sử dụng là không tin cậy.
  • Áp dụng các biện pháp để dọn dẹp nó, ví dụ như lọc hoặc danh sách trắng.
Trong trường hợp của Altoro Mutual, một giải pháp có thể là lọc bất kỳ ký tự nào không phải chữ và số đến từ các trường Tên người dùng và Mật khẩu.
Để biết thêm thông tin về SQL injection và các biện pháp đối phó có thể, hãy đọc trang kiến thức OWASP về SQL Injection (xem phần Tài nguyên)
Rò rỉ thông tin
Một kẻ tấn công nhất định có thể thăm dò một ứng dụng để cố nhận biết các điểm yếu. Ví dụ, một kẻ tấn công có thể trích xuất thông tin theo nhiều cách khác nhau:
  • Khám phá ứng dụng bằng thủ công để tìm ra các thư mục ẩn.
  • Bắt buộc các ngoại lệ một cách có hệ thống để xem ứng dụng có cung cấp các chi tiết ngoại lệ không.
  • Quét HTML với các nhận xét để lộ ra các chi tiết về cơ sở hạ tầng và hành vi của ứng dụng.
  • Nhập một cách có hệ thống các tên người dùng để tìm ra các tài khoản hiện có.
Ứng dụng Altoro Mutual làm rò rỉ các tên người dùng hiện có trong hệ thống. Ví dụ, trong Hình 6, việc nhập một tên người dùng và mật khẩu không chính xác đưa ra thông báo lỗi sau "Đăng nhập không thành công: Chúng tôi xin lỗi, nhưng không tìm thấy tên người dùng này trong hệ thống của chúng tôi. Xin vui lòng thử lại".

Hình 6. Ứng dụng này nói rõ ràng rằng không tìm thấy người dùng trong hệ thống
Trang đăng nhập để lộ ra người dùng không tồn tại

Tiếp theo, kẻ tấn công dùng thử tên người dùng jsmith và ứng dụng web Altoro Mutual đưa ra thông báo sau: "Đăng nhập không thành công: Mật khẩu của bạn dường như không hợp lệ. Xin vui lòng nhập lại mật khẩu của bạn một cách cẩn thận". Từ đó, những kẻ tấn công biết rằng có một tài khoản người dùng tên là jsmith. Với hiểu biết này, kẻ tấn công có thể tập trung vào việc bẻ khóa mật khẩu, có lẽ cố gắng đoán nó bằng một cuộc tấn công bắt ép thô bạo.

Hình 7. Ứng dụng Altoro Mutual rò rỉ sự tồn tại của tên người dùng jsmith
Trang đăng nhập để lộ ra một người dùng có tên đó đang tồn tại

Trong trường hợp này, việc sửa chữa sẽ là tạo ra một thông báo đăng nhập chung chung mà không nói chính xác những gì không thành công, ví dụ: "Đăng nhập không thành công: Tên người dùng hoặc mật khẩu không hợp lệ. Xin vui lòng nhập lại các thông tin của bạn một cách cẩn thận".
Các biện pháp đối phó
Rò rỉ thông tin là một cái gì đó phải được xem xét trong ngữ cảnh của ứng dụng và ý thức của các nhà phát triển là cách bảo vệ tốt nhất. Với mục tiêu đó trong tâm trí, có các biện pháp giảm nhẹ khác nhau để các nhà phát triển xem xét.
  • Xóa mã HTML của tất cả các nhận xét để lộ ra bất cứ điều gì về ứng dụng.
  • Không hiển thị các trường hợp ngoại lệ cụ thể trong trình duyệt. Nếu phải ghi nhật ký chúng, hãy lưu chúng trên máy chủ và hiển thị một lỗi chung chung.
  • Đừng để lộ ra phần xác thực nào không thành công.
  • Ngoài ra, cấu hình máy chủ web và các giá trị thiết lập máy chủ ứng dụng để ngăn chặn chuyển hướng tùy ý trên các trang web và ứng dụng.
Danh sách các rò rỉ thông tin này tất nhiên là chưa đầy đủ. Hãy tìm các rò rỉ khác cụ thể cho ứng dụng và môi trường chạy.
Bạn có thể tìm thêm thông tin trên trang kiến thức OWASP về rò rỉ thông tin.
Giả mạo tham số
Kiểu tấn công này nhằm mục đích xử lý các tham số được truyền đến một ứng dụng. Hãy xem xét một ứng dụng được rất viết tồi cho phép máy khách đặt giá để mua một mặt hàng. Một ứng dụng như vậy có thể gửi các yêu cầu sau đây:
http://somedomain/myStore?item=1234&price=$200

Nếu logic nghiệp vụ không thực hiện bất kỳ loại kiểm tra hai lần trên phía máy chủ, thì một kẻ tấn công có thể thay đổi giá để nhận được mặt hàng có giá rẻ hơn. Việc cho phép giá được thiết lập từ phía máy khách rõ ràng là một sai lầm trong trường hợp này.
Các biện pháp đối phó
  • Để khắc phục trường hợp cụ thể này, bạn có thể thay đổi mã để có được giá từ một cơ sở dữ liệu ở phía máy chủ, tránh giả mạo giá.
  • Ngăn ngừa cuộc tấn công này gồm có xác nhận hợp lệ tham số và xem xét cẩn thận logic của ứng dụng.
Để biết thêm thông tin về giả mạo tham số và các biện pháp đối phó có thể, hãy đọc trang kiến thức OWASP về giả mạo tham số trên web (xem phần Tài nguyên).
Đầu độc cookie
Một cookie là thông tin được gửi từ máy chủ đến trình duyệt, được lưu thành các cặp giá trị/khóa trong một tệp văn bản hoặc bộ nhớ. Các ứng dụng web đã tạo ra nó có thể được sử dụng nội dung của nó. Đầu độc cookie xảy ra khi nội dung của cookie bị sửa đổi sau khi thực hiện một ứng dụng web. Điều này là tương tự như giả mạo tham số.
Các biện pháp đối phó
  • Các biện pháp đối phó với đầu độc cookie bao gồm xác nhận hợp lệ tham số và kiểm tra cẩn thận logic và mã của ứng dụng.
  • Cũng có thể áp dụng cơ chế bảo mật nâng cao.
    • Một cách tiếp cận phổ biến là sử dụng chữ ký số để kiểm tra xem dữ liệu lưu trữ của tệp văn bản đã không bị giả mạo.
    • Một biện pháp đối phó là bảo vệ cookie bằng cách mã hóa nó trong quá trình truyền dẫn để giảm thiểu nguy cơ thay đổi và rình mò trong lúc truyền dẫn.
Đầu độc cookie được thảo luận trên trang OWASP cho các lỗ hổng đầu vào không được xác nhận hợp lệ (xem phần Tài nguyên). 

Tích hợp bảo mật trong quá trình phát triển
Bảo mật đang trở thành một phần thiết yếu của việc phát triển ứng dụng web, cũng như, việc phát triển ứng dụng web di động. Nhiều tổ chức dành cho việc cung cấp chức năng một vị trí quan trọng đặc biệt. Tuy nhiên, người ta cho rằng chi phí để trang bị thêm chức năng sửa chữa lỗi bảo mật là đáng kể. Vì vậy, thật sáng suốt để đặt thử nghiệm và xem xét lại bảo mật làm một phần thiết yếu của quá trình phát triển.
Bảo mật có hiệu quả nhất khi nó được tích hợp trong suốt cả quá trình phát triển, từ thiết kế đến triển khai.
Giai đoạn thiết kế
Trong quá trình thiết kế, hãy xác định xem phải bảo vệ những thông tin nào, có các rủi ro nào và đã có sẵn các biện pháp đối phó nào. Nếu có thể, hãy có các chuyên gia bảo mật công nghệ thông tin (IT) của tổ chức trong lúc thảo luận và có các quyết định ngay từ những giai đoạn đầu. Điều này làm giảm các rủi ro về các lỗ hổng được tìm ra sau này trong chu kỳ phát triển. Việc phát hiện ra sau này dẫn đến các giải pháp kém tối ưu, cần bổ sung rất tốn kém để giải quyết. Hãy xác định các tình huống thực tế để thử nghiệm ở giai đoạn thiết kế. Điều này sẽ giúp thiết lập một quá trình thống nhất để thử nghiệm trong suốt vòng đời phát triển. Việc thử nghiệm bảo mật tăng lên (ví dụ như thử nghiệm thâm nhập) được thực hiện ở giai đoạn triển khai giúp tổ chức tối ưu hóa các tập kỹ năng cần thiết để đảm bảo phát triển ứng dụng tốt.
 
Giai đoạn phát triển
Đào tạo các nhà phát triển về các lỗ hổng phổ biến nhất và các biện pháp mã hóa bảo mật. Trong việc xem xét lại mã, hãy tập trung vào các vấn đề bảo mật và có sự tham gia của các chuyên gia bảo mật của tổ chức. Thực hiện các việc thử nghiệm bảo mật, xem xét lại chúng và đưa chúng vào bất kỳ các bộ kiểm tra tự động nào. Lập kế hoạch cho nhóm phát triển để sẵn sàng giải quyết các vấn đề bảo mật trong quá trình xem xét lại và thử nghiệm mã.
 
Giai đoạn triển khai
Kiểm tra kỹ lưỡng các ứng dụng đã hoàn thành trong một môi trường chuẩn bị sản xuất. Giai đoạn thử nghiệm này có thể bao gồm thử nghiệm thâm nhập vào ứng dụng bởi một nhóm bên ngoài hoặc bằng các công cụ quét bảo mật tự động. Hướng dẫn thực hành quản trị công nghệ thông tin thường định ra các tiêu chí để phê duyệt cuối cùng.
 
Giai đoạn quản lý
Sau khi triển khai, hãy định kỳ giám sát ứng dụng và môi trường của nó đối với các cuộc tấn công và các lỗ hổng có thể bằng cách sử dụng công cụ quét, thử nghiệm thâm nhập và kiểm toán các bản ghi nhật ký. Thiết lập một quy trình rõ ràng để thay đổi môi trường một cách an toàn và áp dụng các bản vá lỗi cho ứng dụng.
 
Tự động hóa thử nghiệm bảo mật trong quá trình phát triển
Khi thiết lập một hướng dẫn thực hành, tự động hóa là một chìa khóa để tạo ra một quá trình bảo mật có thể lặp lại và thích hợp trong suốt chu kỳ phát triển. Các sản phẩm Rational AppScan của IBM cung cấp các công cụ có thể quét mã để giúp các nhà phát triển tìm ra các lỗ hổng. Quá trình sau phát triển để giám sát các ứng dụng đã triển khai cũng có thể sử dụng lại các công cụ quét tự động. Điều này sẽ giữ cho ứng dụng web đã triển khai được giám sát một cách thích hợp và giúp phát hiện các lỗi bảo mật vô tình được đưa vào khi một ứng dụng hoặc cơ sở hạ tầng thay đổi.
Họ các sản phẩm Rational AppScan cung cấp đầy đủ sự tự động hóa cho các hoạt động này trong suốt các giai đoạn phát triển và triển khai.
Giai đoạn phát triển
  • Ấn bản Rational AppScan Source: Đối với nhà phát triển ứng dụng, công cụ này cung cấp phân tích mã theo "hộp trắng" sao cho các nhà phát triển có thể xác định các vấn đề ở giai đoạn phát triển sớm nhất. Nó cũng cung cấp thông tin cho các nhà phát triển về các lỗ hổng có thể đã tìm thấy và tư vấn cách khắc phục.
  • Ấn bản Rational AppScan Tester: Với nhóm đảm bảo chất lượng (QA), công cụ này tạo điều kiện thuận lợi cho việc tích hợp và tự động hóa thử nghiệm bảo mật trong quá trình đảm bảo chất lượng. Các nhà thử nghiệm có thể thêm nó vào môi trường thử nghiệm hiện có của mình để tích hợp việc thử nghiệm bảo mật trong việc kiểm tra chức năng và hiệu năng.
  • Ấn bản Rational AppScan Build: Phiên bản này hỗ trợ tích hợp quét bảo mật trong quá trình xây dựng. Nó tích hợp với các hệ thống quản lý xây dựng, như là Rational® Build Forge® và cũng có thể định hướng các báo cáo tới các nhà phát triển thông qua phần mềm quản lý lỗi, ví dụ như Rational® Clear Quest®.
Giai đoạn triển khai
  • Ấn bản Rational AppScan Standard: Đối với kiểm toán viên bảo mật, phiên bản này thực hiện kiểm tra hộp đen của một ứng dụng đã triển khai. Kiểm toán viên có thể quy định URL của một ứng dụng hiện có (tốt nhất là trên một hệ thống chuẩn bị sản xuất) và công cụ phát hiện ra ứng dụng và quét các lỗ hổng đã biết. Một danh sách các lỗ hổng ưu tiên được tạo ra, cùng với thông tin chi tiết về từng lỗ hổng và các biện pháp giảm nhẹ có thể. Việc tạo các báo cáo tùy chỉnh để phân phát cho các nhóm phát triển và quản lý cũng được hỗ trợ.
  • Ấn bản Rational AppScan Enterprise: Đây là một công cụ nhiều người dùng, dựa trên web cho các nhóm phải mở rộng quét ứng dụng trong toàn doanh nghiệp và theo cách tập trung. Giống như Ấn bản Rational AppScan Standard, nó quét các ứng dụng hiện có và tạo các báo cáo với các danh sách ưu tiên và các nhiệm vụ khắc phục. Nó có thể giúp phân bổ trách nhiệm để khắc phục các vấn đề.
Xem phần Tài nguyên để biết thêm thông tin về họ các sản phẩm Rational AppScan và một liên kết đến nguồn Hướng dẫn Đỏ của IBM (IBM® Red guide®) về cách họ các sản phẩm Rational AppScan có thể giúp tự động hóa và tích hợp bảo mật trong quá trình phát triển.

Những thách thức đáng chú ý của việc truy cập ứng dụng web từ các thiết bị di động
Nhiều rủi ro đối với các ứng dụng và các thiết bị là một sự mở rộng cho các lỗ hổng của ứng dụng máy tính để bàn hiện nay. Các biện pháp hiện tại để nhận dạng và kiểm soát truy cập nằm ngoài phạm vi của bài này, nhưng việc quản trị các ứng dụng web đã bao trùm các lĩnh vực tiêu chuẩn gồm có:
  • Quét ứng dụng với các lỗ hổng đã biết.
  • Kiểm soát truy cập.
  • Nhận dạng và xác thực người dùng.
  • Nhận dạng và quản lý điểm cuối.
  • Phần mềm độc hại.
Đọc tài liệu Sách Đỏ của IBM (IBM® Redbooks®) được trích dẫn trong phần Tài nguyên để tìm hiểu thêm về họ các sản phẩm của IBM có thể tích hợp bảo mật. Ngoài ra, có thể tìm thêm thông tin về họ các sản phẩm IBM® Tivoli® tại trang web Giải pháp Bảo mật ứng dụng Web của IBM (IBM Web Application Security Solutions).
Các thiết bị di động đưa ra một tập các thách thức bổ sung do tính chất cá nhân và di động rất cao của chúng. Các thiết bị di động dễ thất lạc hơn. Điện thoại thông minh bỏ quên trên xe taxi hoặc máy bay bởi vì nó trượt ra khỏi túi là một kịch bản quá quen thuộc. Các điện thoại thông minh cũng là các mục tiêu bị đánh cắp do kích thước nhỏ của chúng. Với những lý do này, phải đưa vào các biện pháp bảo mật bổ sung cho các ứng dụng web có thể truy cập qua các thiết bị di động.
Các lĩnh vực bổ sung cho quản trị doanh nghiệp để giải quyết khi triển khai các thiết bị di động gồm có:
  • Xác thực nhiều yếu tố. Kết hợp hai phương pháp xác thực, ví dụ, mật khẩu và một thiết bị đọc dấu vân tay nếu có sẵn trên thiết bị.
  • Kiểm soát truy cập chi tiết. Những người dùng nên được phép truy cập chính xác vào các tài nguyên mà họ cần để thực hiện công việc của mình, chứ không cần nhiều hơn. Bất kỳ cơ chế kiểm soát truy cập nào cũng phải càng chi tiết càng tốt.
  • Hạn chế truy cập: Cho phép truy cập vào tài nguyên mạng nội bộ từ internet với các mạng riêng ảo (VPN).
  • Mã hóa dữ liệu. Phối hợp các khả năng thiết bị với các yêu cầu đối với dữ liệu nhạy cảm.
  • Quản lý. Nếu cho phép thông tin nhạy cảm, thì với các thiết bị hay bị mất hoặc bị đánh cắp nên áp dụng xóa sạch cho an toàn.
Tóm tắt
Ứng dụng Web 2.0 cho các thiết bị máy tính để bàn và di động chia sẻ nhiều vấn đề bảo mật như nhau và nên cũng chia sẻ nhiều biện pháp đối phó như nhau. Các nhà phát triển phải được đào tạo về các lỗ hổng phổ biến nhất và giải quyết chúng trong suốt cả chu kỳ phát triển. Việc quét các lỗ hổng tự động liên tục trong quá trình phát triển và triển khai cũng được yêu cầu để giữ cho các ứng dụng được an toàn. Các thiết bị di động đưa ra một tập các thách thức đáng chú ý, riêng của mình do tính chất cá nhân và di động của chúng. Lập kế hoạch về cách giữ an toàn dữ liệu nếu thiết bị bị đánh cắp hoặc bị mất trước khi bạn triển khai các giải pháp di động.

Tài nguyên
Học tập
Lấy sản phẩm và công nghệ
Nguồn IBM



Bookmark and Share
Posted by Unknown at 5:40 PM
Labels:

0 comments:

Post a Comment

Next previous home
Subscribe to: Post Comments (Atom)

Cộng đồng yêu thiết kế Việt Nam Thiet ke website, danang