vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi cs vi vi vi vi vi vi vi es en en vi vi vi vi vi vi vi en en en vi vi ceb en en vi te en hbs_lat vi te en kn vi vi vi vi vi vi vi vi en vi en en vi es fr vi tr vi vi en en vi en en vi en en vi en vi hi vi vi vi vi en en vi vi vi es en vi vi vi ceb ko en en kn vi vi vi vi vi vi vi vi vi vi vi vi vi en fr vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi nb vi vi vi

--Liên kết-- Chính phủ CIO Trung tâm chính phủ điện tử vietnamnet.vn ĐCS Việt Nam TP Hồ Chí Minh Đài tiếng nói Việt Nam Thủ đô Hà Nội Tập chí ĐCS Quốc Hội TP Đà Nẵng Thừa Thiên Huế TP Hải Phòng An Giang Bà Rịa - Vũng Tàu Bắc Ninh Bình Dương Binh Phước Bình Thuận Cà Mau Cần thơ
TÀI LIỆU - BÁO CÁO
Chữ ký web JSON - JSON Web Signature (JWS)
Chữ ký Web JSON (JWS) đại diện cho nội dung được bảo mật bằng chữ ký số hoặc Mã xác thực tin nhắn (MAC) bằng cách sử dụng cấu trúc dữ liệu dựa trên JSON. Các thuật toán và số nhận dạng mật mã để sử dụng với đặc điểm kỹ thuật này được mô tả trong thông số kỹ thuật Thuật toán web JSON Web Algorithms (JWA) một cách tách biệt và trong danh sách của tổ chức cấp phát số hiệu chuẩn Internet (IANA). Các khả năng mã hóa liên quan được mô tả trong thông số kỹ thuật Mã hóa web JSON Web Encryption (JWE). JWS cũng là thành phần cuối của mã thông báo web JSON Web Token (JWT) và có vai trò quan trọng nhất trong việc bảo mật của mã thông báo này.
Bài viết dựa trên tài liệu theo dõi tiêu chuẩn mở Internet. Đây là sản phẩm của nhóm chuyên viên kỹ thuật Internet (IETF) và hoành thành vào tháng 05 năm 2015. Những tác giả chính của tiêu chuẩn là M. Jones làm việc tại Microsoft, J. Bradley đến từ Ping indentity và N. Sakirumra đến từ NRI. Nó là sản phẩm thể hiện sự chung sức của cộng đồng IETF đồng thời nó đã nhận được đánh giá công khai và được phê duyệt đề xuất bản bởi khối chỉ đạo kỹ thuật Internet (IESG). Tài liệu này là thành phần đi kèm của tiêu chuẩn cho mã thông báo web JWT. Đây là tài liệu mở nhưng dễ hiểu và dễ sử dụng, tài liệu được sử dụng như một phần của của tài liệu chính JWT, mục đích của tài liệu là khẳng định yếu tố mã hóa. Đây là phiên bản duy nhất và vẫn được giữ được sự tin cậy cao trong các tiêu chuẩn mạng.
JWS hay JSON Web Signature là một dạng chữ kỹ có tác dụng xác minh chính trong JWT được viết với ngôn ngữ JavaScript Object Notaion (JSON) trên nền tảng web. Về mặt kỹ thuật JWS đại diện cho nội dung được ký số hoặc MACed bằng cách sử dụng cấu trúc dữ liệu JSON và mã hóa base64url. Các cấu trúc dữ liệu JSON này có thể chứa khoảng trắng hoặc ngắt dòng trước hoặc sau bất kỳ giá trị JSON hoặc ký tự cấu trúc nào, phù hợp với định dạng dữ liệu của JSON được viết chi tiết trong RFC 7159 [RFC7159]. JWS đại diện cho các giá trị logic này (mỗi giá trị được định nghĩa trong Phần 2):
Đối với mỗi một JWS, các thành phần JOSE Header là sự kết hợp của các giá trị này:
- JWS Protected Header: Giá trị này khi JWS sử dụng tuần tự hóa JWS Compact.
Hình 1: Giá trị của JWS trong JWT
2. Tiến trình tuần tự JWS
JWS sử dụng một trong hai cách tuần tự hóa: Tuần tự hóa JWS Compact hoặc Chuỗi tuần tự JWS JSON. Các ứng dụng cụ thể sử dụng thông số kỹ thuật này cần chỉ định các tính năng tuần tự hóa và tuần tự hóa nào được sử dụng cho ứng dụng đó. Ví dụ: các ứng dụng có thể chỉ định rằng chỉ sử dụng tuần tự hóa JWS JSON, chỉ sử dụng JWS JSON cho một chữ ký hoặc giá trị MAC; hoặc cũng có thể sử dụng hỗ trợ cho nhiều chữ ký hoặc giá trị MAC. Việc triển khai JWS chỉ cần triển khai các tính năng cần thiết cho các ứng dụng mà chúng được thiết kế để hỗ trợ.
Đối với tuần tự hóa JWS Compact, nó đại diện cho nội dung được ký kỹ thuật số hoặc MACed dưới dạng một chuỗi nhỏ gọn, an toàn cho URL. Chuỗi này là:
BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
Chỉ một chữ ký hoặc điện chỉ MAC được hỗ trợ bởi JWS Compact và nó không cung cấp cú pháp nào để đại diện cho giá trị JWS Unprotected Header.
Đối với tuần tự hóa JWS JSON, nó đại diện cho nội dung được ký số hoặc MACed dưới dạng đối tượng JSON. Biểu diễn này không được tối ưu hóa cho sự gọn nhẹ cũng như không an toàn cho URL. Chuỗi này sẽ là:
Hình 2: Ví dụ về chữ ký web JSON không có mã hóa bí mật base64
Hình 3: Ví dụ về chữ ký web JSON có mã hóa bí mật base64
3. Tiêu đề JOSE
Đối với JWS, các thành phần của (các) đối tượng JSON đại diện cho tiêu đề JOSE mô tả chữ ký số hoặc MAC được áp dụng cho JWS Protected Header và JWS Payload và các thuộc tính bổ sung tùy chọn của JWS. Tên tham số tiêu đề trong JOSE PHẢI là duy nhất; Bộ phân tích cú pháp JWS PHẢI từ chối các JWS có tên tiêu đề trùng lặp hoặc sử dụng bộ phân tích cú pháp JSON chỉ trả về tên thành viên trùng lặp về mặt từ vựng, như được chỉ định trong ECMAScript 5.1 [ECMAScript].
Có ba lớp tên Tham số tiêu đề: Tên tham số tiêu đề đã đăng ký, tên tham số tiêu đề công khai và tên tham số tiêu đề riêng.
Tên tham số tiêu đề đã đăng ký bao gồm các giá trị dưới đây:
Xác định thuật toán mật mã được sử dụng để bảo mật JWS. Giá trị Chữ ký JWS không hợp lệ nếu giá trị "alg" không đại diện cho thuật toán được hỗ trợ hoặc nếu không có khóa để sử dụng với thuật toán đó được liên kết với bên đã ký kỹ thuật số hoặc MACed nội dung. các giá trị "alg" phải được đăng ký trong sổ đăng ký "Thuật toán mã hóa và chữ ký web JSON" của IANA do [JWA] thiết lập hoặc là giá trị chứa Tên chống va chạm. Giá trị "alg" là một chuỗi ASCII phân biệt chữ hoa chữ thường có chứa giá trị StringOrURI. Thông số Header này phải có mặt và phải được hiểu và xử lý bởi các triển khai.
Là một URI [RFC3986] đề cập đến một tài nguyên cho một tập hợp các khóa công khai được mã hóa JSON, một trong số đó tương ứng với khóa được sử dụng để ký kỹ thuật số JWS. Các khóa phải được mã hóa dưới dạng bộ JWK [JWK]. Giao thức được sử dụng để lấy tài nguyên phải cung cấp khả năng bảo vệ toàn vẹn; một yêu cầu HTTP GET để truy xuất bộ JWK phải sử dụng bảo mật lớp truyền tải (TLS) [RFC2818] [RFC5246]; và danh tính của máy chủ phải được xác thực. Việc sử dụng tham số tiêu đề này là tùy chọn.
Là khóa công khai tương ứng với khóa dùng để ký điện tử JWS. Khóa này được biểu diễn dưới dạng Khóa web JSON [JWK]. Việc sử dụng tham số tiêu đề này là tùy chọn.
Là một gợi ý cho biết khóa nào đã được sử dụng để bảo mật JWS. Tham số này cho phép người khởi tạo báo hiệu rõ ràng về sự thay đổi khóa cho người nhận. Cấu trúc của giá trị "kid" là không xác định. Giá trị của nó phải là một chuỗi phân biệt chữ hoa chữ thường. Việc sử dụng tham số tiêu đề này là tùy chọn.
Khi được sử dụng với JWK, giá trị "kid" được sử dụng để khớp với giá trị tham số JWK "kid".
Là URI [RFC3986] đề cập đến tài nguyên cho chứng chỉ khóa công khai X.509 hoặc chuỗi chứng chỉ [RFC5280] tương ứng với khóa được sử dụng để ký kỹ thuật số JWS. Tài nguyên được xác định phải cung cấp bản đại diện của chứng chỉ hoặc chuỗi chứng chỉ phù hợp với RFC 5280 [RFC5280] ở dạng được mã hóa PEM. Chứng chỉ có chứa phải là chứng chỉ đầu tiên. Điều này CÓ THỂ được theo sau bởi các chứng chỉ bổ sung, với mỗi chứng chỉ tiếp theo là chứng chỉ được sử dụng để chứng nhận chứng chỉ trước đó. Giao thức được sử dụng để lấy tài nguyên phải cung cấp khả năng bảo vệ toàn vẹn; một yêu cầu HTTP GET để truy xuất chứng chỉ PHẢI sử dụng TLS [RFC2818] [RFC5246]; và danh tính của máy chủ PHẢI được xác thực. Việc sử dụng tham số tiêu đề này là tùy chọn.
Là tiêu đề chứa chứng chỉ khóa công khai X.509 hoặc chuỗi chứng chỉ [RFC5280] tương ứng với khóa được sử dụng để ký kỹ thuật số JWS. Chứng chỉ hoặc chuỗi chứng chỉ được biểu diễn dưới dạng một mảng JSON của các chuỗi giá trị chứng chỉ. Mỗi chuỗi trong mảng là một giá trị chứng chỉ PKIX được mã hóa base64 (Phần 4 của [RFC4648] - không được mã hóa base64url) DER [ITU.X690.2008]. Chứng chỉ có chứa khóa công khai tương ứng với khóa được sử dụng để ký điện tử JWS phải là chứng chỉ đầu tiên. Điều này có thể được theo sau bởi các chứng chỉ bổ sung, với mỗi chứng chỉ tiếp theo là chứng chỉ được sử dụng để chứng nhận chứng chỉ trước đó. Người nhận phải xác thực chuỗi chứng chỉ theo RFC 5280 [RFC5280] và coi chứng chỉ hoặc chuỗi chứng chỉ là không hợp lệ nếu xảy ra bất kỳ lỗi xác thực nào. Việc sử dụng tham số tiêu đề này là tùy chọn.
(X.509 Certificate SHA-1 Thumbprint)
Là bản sao SHA-1 được mã hóa base64url (còn gọi là thông báo) của mã hóa DER của chứng chỉ X.509 [RFC5280] tương ứng với khóa được sử dụng để ký số JWS. Việc sử dụng tham số tiêu đề này là tùy chọn.
"x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
Là một dấu nhỏ SHA-256 được mã hóa base64url (còn gọi là thông báo) của mã hóa DER của chứng chỉ X.509 [RFC5280] tương ứng với khóa được sử dụng ký điện tử JWS. Việc sử dụng tham số tiêu đề này là tùy chọn.
"typ" (Type) Header Parameter
Được các ứng dụng JWS sử dụng để khai báo loại phương tiện [IANA.MediaTypes] của JWS hoàn chỉnh này. Điều này được thiết kế để ứng dụng sử dụng khi có thể có nhiều hơn một loại đối tượng trong cấu trúc dữ liệu ứng dụng có thể chứa JWS; ứng dụng có thể sử dụng giá trị này để phân biệt giữa các loại đối tượng khác nhau có thể có mặt. Nó thường sẽ không được các ứng dụng sử dụng khi loại đối tượng đã được biết trước. Tham số này bị bỏ qua bởi các triển khai JWS; bất kỳ quá trình xử lý tham số này được thực hiện bởi ứng dụng JWS. Việc sử dụng tham số tiêu đề này là tùy chọn.
Theo RFC 2045 [RFC2045], tất cả các giá trị kiểu phương tiện, giá trị kiểu con và tên tham số không phân biệt chữ hoa chữ thường. Tuy nhiên, các giá trị tham số phân biệt chữ hoa chữ thường trừ khi được chỉ định khác cho tham số cụ thể.
Để giữ cho thông điệp gọn gàng trong các tình huống phổ biến, nhà sản xuất nên bỏ qua tiền tố "ứng dụng /" của giá trị loại phương tiện trong Tham số tiêu đề "typ" khi không có '/' nào khác xuất hiện trong giá trị loại phương tiện. Người nhận sử dụng giá trị loại phương tiện PHẢI coi nó như thể "application /" đã được thêm vào trước bất kỳ giá trị "typ" nào không chứa '/'. Ví dụ: giá trị "typ" của "example" NÊN được sử dụng để đại diện cho loại phương tiện "ứng dụng / ví dụ", trong khi loại phương tiện "application / example; part =" 1/2 "" không thể được rút ngắn thành "example; phần = "1/2" ".
Giá trị "typ" là "JOSE" có thể được sử dụng bởi các ứng dụng để chỉ ra rằng đối tượng này là JWS hoặc JWE bằng cách sử dụng JWS Compact Serialization hoặc JWE Compact Serialization. Giá trị "typ" "JOSE + JSON" có thể được ứng dụng sử dụng để chỉ ra rằng đối tượng này là JWS hoặc JWE bằng cách sử dụng JWS JSON Serialization hoặc JWE JSON Serialization. Các ứng dụng cũng có thể sử dụng các giá trị kiểu khác.
Được các ứng dụng JWS sử dụng để khai báo loại phương tiện [IANA.MediaTypes] của nội dung được bảo mật (tải trọng). Điều này được thiết kế để ứng dụng sử dụng khi có thể có nhiều hơn một loại đối tượng trong JWS Payload; ứng dụng có thể sử dụng giá trị này để phân biệt giữa các loại đối tượng khác nhau có thể có mặt. Nó thường sẽ không được các ứng dụng sử dụng khi loại đối tượng đã được biết trước. Tham số này bị bỏ qua bởi các triển khai JWS; bất kỳ quá trình xử lý tham số này được thực hiện bởi ứng dụng JWS. Việc sử dụng tham số h này là tùy chọn.
Theo RFC 2045 [RFC2045], tất cả các giá trị kiểu phương tiện, giá trị kiểu con và tên tham số không phân biệt chữ hoa chữ thường. Tuy nhiên, các giá trị tham số phân biệt chữ hoa chữ thường trừ khi được chỉ định khác cho tham số cụ thể.
Để giữ cho thông điệp gọn gàng trong các tình huống phổ biến, khuyến cáo rằng nhà sản xuất bỏ qua tiền tố "application /" của giá trị loại phương tiện trong Thông số tiêu đề "cty" khi không có '/' nào khác xuất hiện trong giá trị loại phương tiện. Người nhận sử dụng giá trị loại phương tiện PHẢI coi nó như thể "application /" được thêm vào trước bất kỳ giá trị "cty" nào không chứa '/'. Ví dụ: giá trị "cty" của "example" NÊN được sử dụng để đại diện cho loại phương tiện "ứng dụng / ví dụ", trong khi loại phương tiện "application / example; part =" 1/2 "" không thể được rút ngắn thành "example; phần = "1/2" ".
"crit" (Critical) Header Parameter
Thông số tiêu đề "crit" (quan trọng) chỉ ra rằng các phần mở rộng cho đặc điểm kỹ thuật này và / hoặc [JWA] đang được sử dụng phải được hiểu và xử lý. Giá trị của nó là một mảng liệt kê các tên thông số tiêu đề có trong Tiêu đề JOSE sử dụng các phần mở rộng đó. Nếu bất kỳ tham số tiêu đề tiện ích mở rộng nào được liệt kê không được người nhận hiểu và hỗ trợ, thì JWS không hợp lệ. Nhà sản xuất không được bao gồm tên tham số tiêu đề được xác định bởi thông số kỹ thuật này hoặc [JWA] để sử dụng với JWS, tên trùng lặp hoặc tên không xuất hiện dưới dạng tên tham số tiêu đề trong tiêu đề JOSE trong danh sách "crit".
Nhà sản xuất không được sử dụng danh sách trống "[]" làm giá trị "crit". Người nhận có thể coi JWS là không hợp lệ nếu danh sách quan trọng chứa bất kỳ tên Thông số tiêu đề nào được xác định bởi đặc tả này hoặc [JWA] để sử dụng với JWS hoặc nếu bất kỳ ràng buộc nào khác về việc sử dụng nó bị vi phạm. Khi được sử dụng, Thông số Header này phải được bảo vệ toàn vẹn; do đó, nó phải xảy ra chỉ trong JWS Protected Header. Việc sử dụng tham số tiêu đề này là tùy chọn. Tham số tiêu đề này phải được hiểu và xử lý bởi các triển khai.
Một ví dụ sử dụng, cùng với trường "exp" (thời gian hết hạn) giả định là:
Tên tham số tiêu đề công khai:
Tên tham số tiêu đề bổ sung có thể được xác định bởi những người sử dụng JWS. Tuy nhiên, để tránh va chạm, bất kỳ tên Tham số tiêu đề mới nào cũng phải được đăng ký trong sổ đăng ký IANA "Các tham số tiêu đề mã hóa và chữ ký web JSON" được thiết lập bởi Tên công khai (một giá trị chứa Tên chống va chạm). Trong mỗi trường hợp, người định nghĩa tên hoặc giá trị cần phải thực hiện các biện pháp phòng ngừa hợp lý để đảm bảo rằng họ đang kiểm soát phần của không gian tên mà họ sử dụng để xác định tên Tham số tiêu đề.
Các tham số tiêu đề mới nên được giới thiệu một cách hạn chế, vì chúng có thể dẫn đến các JWS không thể tương tác.
Tên tham số tiêu đề riêng:
Nhà sản xuất và người tiêu dùng JWS có thể đồng ý sử dụng tên Tham số tiêu đề là tên riêng (tên không phải là tên tham số tiêu đề đã đăng ký) hoặc tên tham số tiêu đề công khai. Không giống như tên tham số tiêu đề công khai, tên tham số tiêu đề riêng có thể bị va chạm và nên được sử dụng một cách thận trọng.
4. Khía cạnh bảo mật
Tất cả các vấn đề bảo mật liên quan đến bất kỳ ứng dụng mật mã nào đều phải được giải quyết bởi các loại mã JWS / JWE / JWK. Trong số các vấn đề này là bảo vệ các khóa bí mật đối xứng và riêng tư bất đối xứng của người dùng và sử dụng các biện pháp đối phó với các cuộc tấn công khác nhau.
Tất cả các cân nhắc bảo mật trong "Cú pháp và xử lý chữ ký XML Phiên bản 2.0" [W3C.NOTE-xmldsig-core2-20130411], cũng áp dụng cho đặc tả này, ngoài những đặc tả dành riêng cho XML. Tương tự như vậy, nhiều phương pháp hay nhất được ghi lại trong "Các phương pháp hay nhất về chữ ký XML" [W3C.NOTE-xmldsig-bestpractices-20130411] cũng áp dụng cho đặc tả này, ngoại trừ những phương pháp dành riêng cho XML.
Có thể thấy JSON Web Signature (JWS) hay chữ ký web JSON khá là phức tạp về mặt lập trình và yêu cầu sự hiểu biết nhất định về code. Tuy nhiên việc nắm bắt được JWS là yếu tố cố lõi của mã thông báo JWT, là yếu tố quan trọng trong việc tổng hợp mã thông báo và mã hóa một cách bất kì. Điều này tránh được sự tấn công của kẻ gian nhờ việc linh hoạt mã hóa. Việc hiểu được cái giá trị cốt lỗi của JWS hay các tiêu đề JSON sẽ giúp việc xây dựng JWT chính xác và hiệu quả.
Thông qua tiêu chuẩn mở này, ta có thêm các khía cạnh về bảo mật để xây dựng các nền tảng mới, đặc biệt nó là thành phần quan trọng trong mã thông báo JWT hay trong tiêu chuẩn OpenID Connect 1.0.
Vũ Cao Minh Đức
Tài liệu tham khảo
1. XML Signature Syntax and Processing Version 2.0
2. JSON Web Signature (https://tools.ietf.org/html/rfc7515)
Quản trị viên, Cục Tin Học Hóa
Lần xem: 2871 Go top
Giới thiệu giao thức truyền thông điệp/giao tiếp nâng cao AMQP ( 08/12/2021)
Giới thiệu tiêu chuẩn mật khẩu dùng một lần HOTP và TOTP ( 08/12/2021)
Giới thiệu các chuẩn giao tiếp trên thiết bị IoT phần II ( 08/12/2021)
Giới thiệu tiêu chuẩn Mạng cục bộ không dây IEEE 802.11ax ( 07/12/2021)
Giới thiệu một số chuẩn khuôn dạng chữ ký số ( 07/12/2021)
Sự kiện nổi bật
Bộ Thông tin và Truyền thông thông báo kết quả đánh giá chuyển đổi số cấp bộ, cấp tỉnh năm 2020 (DTI)
Đẩy mạnh triển khai Kế hoạch cung cấp 100% DVCTT mức độ đủ điều kiện trong năm 2021
Phê duyệt Chiến lược phát triển Chính phủ điện tử hướng tới Chính phủ số giai đoạn 2021-2025, định hướng đến năm 2030
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử 6 tháng đầu năm 2020 (Công văn số 1735/BTTTT-THH ngày 12 tháng 5 năm 2020)
Nghị định về quản lý, kết nối, chia sẻ dữ liệu số của cơ quan nhà nước.
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử quý I năm 2020 (Công văn số 634/BTTTT-THH ngày 27 tháng 02 năm 2020)
Bộ Thông tin và Truyền thông: ban hành Khung Kiến trúc Chính phủ điện tử Việt Nam, phiên bản 2.0
BỘ THÔNG TIN VÀ TRUYỀN THÔNG: YÊU CẦU BÁO CÁO SỐ LIỆU VỀ PHÁT TRIỂN CHÍNH PHỦ ĐIỆN TỬ QUÝ IV/2019 (CÔNG VĂN SỐ 4045/BTTTT-THH NGÀY 13 THÁNG 11 NĂM 2019)
Bộ Thông tin và Truyền thông: Hướng dẫn các Bộ, ngành, địa phương xây dựng Kế hoạch ứng dụng CNTT trong hoạt động của CQNN năm 2020
Bộ Thông tin và Truyền thông: Ban hành Khung tham chiếu ICT phát triển đô thị thông minh
Ý kiến về Trang thông tin điện tử Cục Tin học hóa?
1. Đạt yêu cầu, 1180 phiếu (88 %)
2. Chưa đạt yêu cầu, 107 phiếu (8 %)
3. Cần thêm chủ đề, 57 phiếu (4 %)
Tổng số phiếu: 1344
THÔNG KÊ TRUY CẬP
Tổng lượt truy cập: 18945461
Người chịu trách nhiệm: Đỗ Công Anh
Chức vụ: Cục trưởng
Trụ sở chính: Tầng 21, Tòa nhà Cục Viễn thông, số 68 đường Dương Đình Nghệ, Yên Hòa, Cầu Giấy, Hà Nội.
Điện thoại: 024.37821766 Fax: 024.35378208
Ghi rõ nguồn "Trang thông tin điện tử Cục Tin học hóa" hoặc "www.aita.gov.vn" khi bạn phát hành lại thông tin từ Website này.

--Links-- Government CIO Electronic Government Center vietnamnet.vn Vietnam Communist Party Ho Chi Minh City Voice of Vietnam Hanoi Capital Communist Party Magazine National Assembly Da Nang City Thua Thien Hue Hai Phong City An Gia


vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi fa en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi nb vi vi vi

--Liên kết-- Chính phủ CIO Trung tâm chính phủ điện tử vietnamnet.vn ĐCS Việt Nam TP Hồ Chí Minh Đài tiếng nói Việt Nam Thủ đô Hà Nội Tập chí ĐCS Quốc Hội TP Đà Nẵng Thừa Thiên Huế TP Hải Phòng An Giang Bà Rịa - Vũng Tàu Bắc Ninh Bình Dương Binh Phước Bình Thuận Cà Mau Cần thơ
TÀI LIỆU - BÁO CÁO
Việt Nam sẽ trở thành quốc gia số vào năm 2030
“Chương trình Chuyển đổi số quốc gia đến năm 2025, định hướng đến năm 2030” vừa được phê duyệt, với tầm nhìn đến năm 2030 Việt Nam trở thành quốc gia số, ổn định và thịnh vượng, tiên phong thử nghiệm các công nghệ và mô hình mới.
Chương trình Chuyển đổi số quốc gia hướng tới mục tiêu kép là vừa phát triển Chính phủ số, kinh tế số, xã hội số, vừa hình thành các doanh nghiệp công nghệ số Việt Nam có năng lực đi ra toàn cầu (Ảnh:Trung tâm giám sát điều hành đô thị thông minh T. P. Huế)
Chương trình xác định tầm nhìn đến năm 2030 Việt Nam trở thành quốc gia số, ổn định và thịnh vượng, tiên phong thử nghiệm các công nghệ và mô hình mới; đổi mới căn bản, toàn diện hoạt động quản lý, điều hành của Chính phủ, hoạt động sản xuất kinh doanh của doanh nghiệp, phương thức sống, làm việc của người dân, phát triển môi trường số an toàn, nhân văn, rộng khắp.
Chương trình Chuyển đổi số quốc gia hướng tới mục tiêu kép là vừa phát triển Chính phủ số, kinh tế số, xã hội số, vừa hình thành các doanh nghiệp công nghệ số Việt Nam có năng lực đi ra toàn cầu, với một số chỉ số cơ bản cụ thể.
Trong đó, về phát triển Chính phủ số, nâng cao hiệu quả, hiệu lực hoạt động, các mục tiêu cơ bản đến năm 2025 của Chương trình là: 80% dịch vụ công trực tuyến mức độ 4, được cung cấp trên nhiều phương tiện truy cập khác nhau, bao gồm cả thiết bị di động; 90% hồ sơ công việc tại cấp bộ, tỉnh; 80% hồ sơ công việc tại cấp huyện và 60% hồ sơ công việc tại cấp xã được xử lý trên môi trường mạng (trừ hồ sơ công việc thuộc phạm vi bí mật nhà nước);
100% chế độ báo cáo, chỉ tiêu tổng hợp báo cáo định kỳ và báo cáo thống kê về inh tế - xã hội phục vụ sự chỉ đạo, điều hành của Chính phủ, Thủ tướng Chính phủ được kết nối, tích hợp, chia sẻ dữ liệu số trên Hệ thống thông tin báo cáo Chính phủ; 100% cơ sở dữ liệu quốc gia tạo nền tảng phát triển Chính phủ điện tử bao gồm các cơ sở dữ liệu quốc gia về Dân cư, Đất đai, Đăng ý doanh  nghiệp, Tài chính, Bảo hiểm được hoàn thành và kết nối, chia sẻ trên toàn quốc; từng bước mở dữ liệu của các cơ quan nhà nước để cung cấp dịch vụ công kịp thời, một lần khai báo, trọn vòng đời phục vụ người dân và phát  triển kinh tế - xã hội;
50% hoạt động kiểm tra của cơ quan quản lý nhà nước được thực hiện thông qua môi trường số và hệ thống thông tin của cơ quan quản lý; và Việt Nam thuộc nhóm 70 nước dẫn đầu về Chính phủ điện tử (EGDI).
Về phát triển kinh tế số, nâng cao năng lực cạnh tranh của nền kinh tế, các mục tiêu đến năm 2025 là đưa kinh tế số Việt Nam chiếm 20% GDP; tỷ trọng kinh tế số trong từng ngành, lĩnh vực đạt tối thiểu 10%; Năng suất lao động hàng năm tăng tối thiểu 7%.
Cùng với đó, Chương trình cũng hướng tới mục tiêu đến năm 2025, Việt Nam thuộc nhóm 50 nước dẫn đầu về CNTT (IDI), nhóm 50 nước dẫn đầu về chỉ số cạnh tranh (GCI) và thuộc nhóm 35 nước dẫn đầu về đổi mới sáng tạo (GII).
Đối với phát triển xã hội số, thu hẹp khoảng cách số, các mục tiêu cơ bản đến năm 2025 bao gồm: Hạ tầng mạng băng rộng cáp quang phủ trên 80% hộ gia đình, 100% xã; Phổ cập dịch vụ mạng di động 4G/5G và điện thoại di động thông minh; Tỷ lệ dân số có tài khoản thanh toán điện tử trên 50%; và Việt Nam thuộc nhóm 40 nước dẫn đầu về an toàn, an ninh mạng (GCI).
Nhận thức đóng vai trò quyết định trong chuyển đổi số
Cũng theo Chương trình Chuyển đổi số quốc gia mới được phê duyệt, Thủ tướng Chính phủ cũng xác định rõ 6 quan điểm, cách tiếp cận của Chương trình, trong đó: Nhận thức đóng vai trò quyết định trong chuyển đổi số; Người dân là trung tâm của chuyển đổi số; Thể chế và công nghệ là động lực của chuyển đổi số; Phát triển nền tảng số là giải pháp đột phá để thúc đẩy chuyển đổi số nhanh hơn, giảm chi phí, tăng hiệu quả; Bảo đảm an toàn, an ninh mạng là then chốt để chuyển đổi số thành công và bền vững, đồng thời là phần xuyên suốt, không thể tách rời của chuyển đổi số; và sự vào cuộc của cả hệ thống chính trị, hành động đồng bộ ở các cấp và sự tham gia của toàn dân là yếu tố bảo đảm sự thành công của chuyển đổi số.
Trên quan điểm đó, Chương trình Chuyển đổi số quốc gia đã vạch ra các nhóm nhiệm vụ, giải pháp cần triển khai nhằm tạo nền mỏng chuyển đổi số; phát triển chính phủ số; phát triển kinh tế số và phát triển xã hội số.
Cụ thể, để tạo nền móng chuyển đổi số, Chương trình xác định, cần chuyển đổi nhận thức về sứ mệnh, sự cần thiết, tính cấp bách của chuyển đổi số trong xã hội, lan truyền từ điểm tới diện, từ một nhóm tổ chức, cá nhân tiên phong tới cộng đồng, bằng những câu chuyện thành công điển hình, có tính thuyết phục cao.
Triển khai nhiệm vụ nêu trên, 4 giải pháp cụ thể được đưa ra là: Người đứng đầu chịu trách nhiệm trực tiếp về chuyển đổi số trong cơ quan, tổ chức, lĩnh vực, địa bàn mình phụ trách; Thành lập và duy trì hoạt động hiệu quả Liên minh Chuyển đổi số để truyền cảm hứng, đi tiên phong; Xây dựng bộ nhận diện chung cho Chương trình Chuyển đổi số quốc gia; Mỗi địa phương chủ động lựa chọn một xã/phường để triển khai thử nghiệm công tác truyền thông, phổ biến các kỹ năng số cơ bản cho người dân.
Về kiến tạo thể chế, theo Chương trình, nhiệm vụ này cần được triển khai theo hướng khuyến khích, sẵn sàng chấp nhận sản phẩm, giải pháp, dịch vụ, mô hình kinh doanh số, thúc đẩy phương thức quản lý mới đối với những mối quan hệ mới phát sinh, bao gồm: Chấp nhận thử nghiệm sản phẩm, giải pháp, dịch vụ, mô hình kinh doanh số; xây dựng khung pháp lý thử nghiệm; Rà soát, sửa đổi, bổ sung hệ thống văn bản quy phạm pháp luật trong các lĩnh vực chuyên ngành; Rà soát, sửa đổi, bổ sung hệ thống văn bản quy phạm pháp luật về doanh nghiệp, khởi nghiệp sáng tạo, sở hữu trí tuệ, thương mại, đầu tư, kinh doanh.
Cùng với đó, cần nghiên cứu đề xuất, sửa đổi, bổ sung văn bản quy phạm pháp luật về CNTT và truyền thông; Nghiên cứu chính sách, quy định cụ thể về thuế, phí để khuyến khích người dân, doanh nghiệp sử dụng, cung cấp các dịch vụ số; Rà soát, sửa đổi các văn bản pháp luật dân sự, hình sự và các luật chuyên ngành theo hướng tăng nặng mức và hình phạt cho các hành vi lừa đảo, gian lận khi giao dịch trên không gian mạng.
Theo Chương trình Chuyển đổi số quốc gia, phát triển hạ tầng số là một trong sáu nhóm nhiệm vụ giải pháp tạo nền móng chuyển đổi số (Ảnh: Zingnews.vn)
Đối với nhóm nhiệm vụ, giải pháp phát triển hạ tầng số, yêu cầu đặt ra là sẵn sàng đáp ứng nhu cầu bùng nổ về kết nối và xử lý dữ liệu, các chức năng về giám sát mạng lưới đến từng nút mạng và bảo đảm an toàn, an ninh mạng được tích hợp sẵn ngay từ khi thiết kế, xây dựng.
Để triển khai nhiệm vụ này, 4 giải pháp cụ thể sẽ được tập trung triển khai, đó là: Xây dựng, phát triển hạ tầng băng rộng; Nâng cấp mạng di động 4G, triển khai mạng di động 5G, kết hợp với yêu cầu tích hợp công nghệ 4G, 5G đối với các sản phẩm điện thoại di động và phổ cập điện thoại di động thông minh; Mở rộng kết nối Internet trong nước, phổ cập tên miền .vn; Phát triển hạ tầng kết nối mạng Internet vạn vật (IoT) và tích hợp cảm biến để chuyển đổi hạ tầng truyền thống thành một bộ phận cấu thành quan trọng của hạ tầng số.
Trong nhóm nhiệm vụ, giải pháp này, việc phổ cập điện thoại di động thông minh - mỗi người dân một điện thoại di động thông minh và phổ cập hạ tầng băng rộng - mỗi hộ gia đình một đường cáp quang có ý nghĩa quan trọng trong việc thúc đẩy tiến trình chuyển đổi số.
Cũng để tạo nền móng chuyển đổi số, Chương trình Chuyển đổi số quốc gia còn đề ra các nhóm nhiệm vụ, giải pháp về Phát triển nền tảng số; Tạo lập niềm tin, bảo đảm an toàn, an ninh mạng; Hợp tác quốc tế, nghiên cứu, phát triển và đổi mới sáng tạo trong môi trường số.
Bên cạnh đó, Chương trình cũng đưa ra một số lĩnh vực cần ưu tiên chuyển đổi số, bao gồm: Y tế, Giáo dục, Tài chính - Ngân hàng, Nông nghiệp, Giao thông vận tải, Năng lượng, Tài nguyên và Môi trường, Sản xuất công nghiệp.
Cơ chế điều phối triển khai Chương trình Chuyển đổi số quốc gia
Về cơ chế điều phối triển khai Chương trình, quyết định của Thủ tướng Chính phủ nêu rõ, Ủy ban quốc gia về Chính phủ điện tử thực hiện chức năng, nhiệm vụ nghiên cứu, đề xuất với Chính phủ, Thủ tướng Chính phủ về chủ trương, chiến lược, cơ chế, chính sách tạo môi trường pháp lý thúc đẩy tiến trình chuyển đổi số hướng tới Chính phủ số, nền kinh tế số và xã hội số; đôn đốc, điều phối chung việc triển hai Chương trình Chuyển đổi số quốc gia.
Ban Chỉ đạo xây dựng Chính phủ điện tử/Chính quyền điện tử của các bộ, cơ quan ngang bộ, cơ quan thuộc Chính phủ và Ủy ban nhân dân các tỉnh, thành phố trực thuộc trung ương đôn đốc, điều phối chung việc triển khai hoạt động chuyển đổi số trong phạm vi bộ, ngành, địa phương mình.
Trong quá trình triển khai, trường hợp cần thiết có sự thay đổi thuộc thẩm quyền của Thủ tướng Chính phủ, Bộ TT&TT tham mưu, đề xuất Thủ tướng Chính phủ xem xét, quyết định. Trường hợp cần thiết có sự thay đổi thuộc thẩm quyền của các bộ, ngành, địa phương, cơ quan thường trực Ban Chỉ đạo xây dựng Chính phủ điện tử/Chính quyền điện tử tham mưu, đề xuất cấp có thẩm quyền xem xét, quyết định./.
Quản trị viên, Cục Tin Học Hóa
Lần xem: 2530 Go top
Chính phủ ban hành Nghị định số 42/2022/NĐ-CP Quy định về việc cung cấp thông tin và dịch vụ công trực tuyến của cơ quan nhà nước trên môi trường mạng ( 27/06/2022)
Hòa Bình sẽ nâng tỷ lệ hồ sơ giải quyết trực tuyến mức cao lên 55% ( 23/02/2022)
Bộ Thông tin và Truyền thông thông báo kết quả đánh giá chuyển đổi số cấp bộ, cấp tỉnh năm 2020 (DTI) ( 19/10/2021)
Sự kiện nội bật
Bộ Thông tin và Truyền thông thông báo kết quả đánh giá chuyển đổi số cấp bộ, cấp tỉnh năm 2020 (DTI)
Đẩy mạnh triển khai Kế hoạch cung cấp 100% DVCTT mức độ đủ điều kiện trong năm 2021
Phê duyệt Chiến lược phát triển Chính phủ điện tử hướng tới Chính phủ số giai đoạn 2021-2025, định hướng đến năm 2030
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử 6 tháng đầu năm 2020 (Công văn số 1735/BTTTT-THH ngày 12 tháng 5 năm 2020)
Nghị định về quản lý, kết nối, chia sẻ dữ liệu số của cơ quan nhà nước.
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử quý I năm 2020 (Công văn số 634/BTTTT-THH ngày 27 tháng 02 năm 2020)
Bộ Thông tin và Truyền thông: ban hành Khung Kiến trúc Chính phủ điện tử Việt Nam, phiên bản 2.0
BỘ THÔNG TIN VÀ TRUYỀN THÔNG: YÊU CẦU BÁO CÁO SỐ LIỆU VỀ PHÁT TRIỂN CHÍNH PHỦ ĐIỆN TỬ QUÝ IV/2019 (CÔNG VĂN SỐ 4045/BTTTT-THH NGÀY 13 THÁNG 11 NĂM 2019)
Bộ Thông tin và Truyền thông: Hướng dẫn các Bộ, ngành, địa phương xây dựng Kế hoạch ứng dụng CNTT trong hoạt động của CQNN năm 2020
Bộ Thông tin và Truyền thông: Ban hành Khung tham chiếu ICT phát triển đô thị thông minh
Ý kiến về Trang thông tin điện tử Cục Tin học hóa?
1. Đạt yêu cầu, 1180 phiếu (88 %)
2. Chưa đạt yêu cầu, 107 phiếu (8 %)
3. Cần thêm chủ đề, 57 phiếu (4 %)
Tổng số phiếu: 1344
THÔNG KÊ TRUY CẬP
Tổng lượt truy cập: 18945550
Người chịu trách nhiệm: Đỗ Công Anh
Chức vụ: Cục trưởng
Trụ sở chính: Tầng 21, Tòa nhà Cục Viễn thông, số 68 đường Dương Đình Nghệ, Yên Hòa, Cầu Giấy, Hà Nội.
Điện thoại: 024.37821766 Fax: 024.35378208
Ghi rõ nguồn "Trang thông tin điện tử Cục Tin học hóa" hoặc "www.aita.gov.vn" khi bạn phát hành lại thông tin từ Website này.


vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en en en en en en en en en en en en en en en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi nb vi vi vi

--Liên kết-- Chính phủ CIO Trung tâm chính phủ điện tử vietnamnet.vn ĐCS Việt Nam TP Hồ Chí Minh Đài tiếng nói Việt Nam Thủ đô Hà Nội Tập chí ĐCS Quốc Hội TP Đà Nẵng Thừa Thiên Huế TP Hải Phòng An Giang Bà Rịa - Vũng Tàu Bắc Ninh Bình Dương Binh Phước Bình Thuận Cà Mau Cần thơ
TÀI LIỆU - BÁO CÁO
Giới thiệu tiêu chuẩn Ngôn ngữ đánh dấu kiểm soát truy cập eXtensible
Trong xu hướng phát triển, ngày càng có nhiều kiểu ngôn ngữ ra đời, mỗi kiểu ngôn ngữ có một kiểu triển khai khác nhau, bảo mật khác nhau, điều này dẫn đến việc khó khăn trong tích hợp hay kết nối các hệ thống với nhau. Đứng trước khó khăn này, Tổ chức phát triển tiêu chuẩn thông tin có cấu trúc (OASIS) đã nghiên cứu, xây dựng và ban hành một kiểu xác định ngôn ngữ chung để dễ dàng quản lý cũng như phát triển chính sách bảo mật.
Động lực để xây dựng XACML là phát triển một ngôn ngữ chính sách dựa trên XML có thể được sử dụng:
- Cung cấp một phương pháp để định nghĩa linh hoạt về thủ tục mà các quy tắc và chính sách được kết hợp với nhau.
- Cung cấp một phương pháp để đối phó với nhiều đối tượng hoạt động với các năng lực khác nhau.
- Cung cấp một phương pháp để đưa ra quyết định ủy quyền dựa trên các thuộc tính của đối tượng và tài nguyên.
- Cung cấp phương pháp xử lý các thuộc tính đa giá trị.
- Cung cấp một phương pháp để ra quyết định ủy quyền dựa trên nội dung của một nguồn thông tin.
- Cung cấp một tập hợp các toán tử logic và toán học về các thuộc tính của đối tượng, tài nguyên và môi trường.
- Cung cấp một phương pháp để xử lý một tập hợp phân tán các thành phần chính sách, đồng thời trừu tượng hóa phương thức để định vị, truy xuất và xác thực các thành phần chính sách.
- Cung cấp một phương pháp để nhanh chóng xác định chính sách áp dụng cho một hành động nhất định, dựa trên các giá trị thuộc tính của chủ thể, nguồn lực và hành động.
- Cung cấp một lớp trừu tượng để cách ly người viết chính sách khỏi các chi tiết của môi trường ứng dụng.
- Cung cấp một phương pháp để chỉ định một tập hợp các hành động phải được thực hiện cùng với việc thực thi chính sách.
Các giải pháp XACML cốt lõi được bao gồm trong Khuyến nghị này. Điều khoản 7 phát triển các mô hình XACML. Điều khoản 8 phát triển ngôn ngữ chính sách. Khoản 10 phát triển các quy tắc xử lý chính sách. Khoản 11 phát triển các hướng dẫn cho người thực hiện.
Trên thực tế, XACML đã được OASIS giới thiệu như một tiêu chuẩn vào năm 2003, nhưng vẫn chưa có nhiều tổ chức ưu chuộng với nó. Điều này là do hầu hết các tổ chức đã không thể hiện sự quan tâm đến việc hướng tới giải pháp XACML để ủy quyền. Một số lý do cho điều này là: nhiều nhà thiết kế và phát triển phần mềm không hiểu rõ về tầm quan trọng và lợi thế của XACML, hơi khó để triển khai giải pháp XACML hơn là hệ thống ủy quyền mã hóa cứng hoặc JDBC điển hình, Hiệu suất của hệ thống ủy quyền dựa trên XACML có thể kém hơn hệ thống ủy quyển mà các tổ chức sử dụng hiện tại, sự phức tạp của việc xác định và quản lý các chính sách XACML.
Một số khái niệm cơ bản và mô hình luồng của XACML
Trong XACML có 5 khái niệm phổ biến và trao đổi qua lại trong mô hình thông tin của XACML, đó là:
- Điểm quản trị chính sách (PAP - Policy Administration Point) là điểm cung cấp các chính sách về chấp nhận hay từ chối quyền truy cập vào hệ thống.
- Điểm quyết định chính sách (PDP - Policy Decision Point) là điểm đánh giá các yêu cầu truy cập dựa trên các chính sách cấp quyền trước khi đưa ra quyết định chấp nhận yêu cầu truy cập.
- Điểm thực thi chính sách (PEP - Policy Enforcement Point) là điểm tiếp nhận yêu cầu truy cập và điều hướng các yêu cầu kiểm tra với chính sách trong hệ thống.
- Điểm thông tin chính sách (PIP - Policy Information Point) là điểm có tác vụ như một nguồn giá trị thuộc tính (tức là tài nguyên, chủ thể, môi trường) sau đó truy vấn và gửi phản hồi về cho PDP quyết định chấp nhận hay từ chối yêu cầu truy cập.
- Điểm truy xuất chính sách (PRP - Policy Retrieval Point) là điểm xác định nơi các chính sách ủy quyền truy cập XACML được lưu trữ, thường là cơ sở dữ liệu hoặc hệ thống tệp. Do đó, PRP không phổ biến trong mô hình luồng quyết định của XACML nhưng nó tồn tại như một khái niệm cụ thể xác định vị trí của chính sách XACML.
Mô hình luồng của XACML như sau:
Hình 1: Mô hình luồng thông tin được xử lý theo XACML
Luồng dữ liệu được luân chuyển trong sơ đồ như sau:
1. PAP viết các chính sách và bộ chính sách và cung cấp chúng cho PDP. Các chính sách hoặc bộ chính sách này đại diện cho chính sách hoàn chỉnh cho một mục tiêu cụ thể.
2. Người yêu cầu truy cập gửi yêu cầu truy cập vào PEP.
3. PEP gửi yêu cầu truy cập tới trình xử lý ngữ cảnh ở định dạng yêu cầu gốc của nó, bao gồm các thuộc tính của chủ thể, tài nguyên, hành động, môi trường và các danh mục khác.
4. Trình xử lý ngữ cảnh xây dựng bối cảnh yêu cầu XACML, tùy chọn thêm các thuộc tính và gửi nó đến PDP.
5. PDP yêu cầu bất kỳ thuộc tính chủ đề, tài nguyên, hành động, môi trường bổ sung nào và các danh mục khác (không được hiển thị) từ trình xử lý ngữ cảnh.
6. Trình xử lý ngữ cảnh yêu cầu các thuộc tính từ PIP.
7. PIP có được các thuộc tính được yêu cầu.
8. PIP trả về các thuộc tính được yêu cầu cho trình xử lý ngữ cảnh.
9. Theo tùy chọn, trình xử lý ngữ cảnh bao gồm tài nguyên trong ngữ cảnh.
10. Trình xử lý ngữ cảnh gửi các thuộc tính được yêu cầu và (tùy chọn) tài nguyên tới PDP. PDP đánh giá chính sách.
11. PDP trả về ngữ cảnh phản hồi (bao gồm cả quyết định ủy quyền) cho trình xử lý ngữ cảnh.
12. Trình xử lý ngữ cảnh chuyển ngữ cảnh phản hồi sang định dạng phản hồi gốc của PEP. Trình xử lý ngữ cảnh trả về phản hồi cho PEP.
13. PEP hoàn thành các nghĩa vụ.
14. (Không hiển thị) Nếu quyền truy cập được cho phép, thì PEP cho phép truy cập vào tài nguyên; nếu không, nó từ chối quyền truy cập.
Các yếu tố trong chính sách XACML
Trong chính sách của XACML, tiêu chuẩn định nghĩa 2 yếu tố chính cấp cao nhất là Kết cấu và Thuộc tính. Các yếu tố này được xây dựng dưa trên việc kết hợp từ hai chính sách hay nhiều chính sách riêng biệt (theo số lượng hệ thống, số lượng ngôn ngữ sử dụng) để tạo thành một chính sách duy nhất áp dụng cho yêu cầu truy cập.
Kết cấu của chính sách XACML gồm 3 phần tử là quy tắc (ruleID), chính sách và bộ chính sách (PolicySet).
- Phần tử “quy tắc” có chứa biểu thức Boolean có thể được đánh giá một cách riêng biệt, nhưng nó không nhằm mục đích được truy cập một cách riêng biệt bởi PDP. Vì vậy, bản thân nó không nhằm mục đích hình thành cơ sở của một quyết định ủy quyền. Nó được dự định chỉ tồn tại một cách biệt lập trong XACML PAP, nơi nó có thể tạo thành đơn vị quản lý cơ bản. “Quy tắc” tồn tại riêng lẻ chỉ trong một trong những tác nhân chính của miền XACML. Các thành phần chính của quy tắc như sau
+ “Mục tiêu” (target) là xác định tập hợp các yêu cầu mà quy tắc được dự định áp dụng dưới dạng biểu thức logic trên các thuộc tính trong yêu cầu.
+ “Hiệu ứng” (effect) là hiệu quả của quy tắc cho biết hệ quả dự kiến của người viết quy tắc của đánh giá “TRUE” cho quy tắc. Hai giá trị được phép là "Cho phép" và "Từ chối".
+ “Điều kiện” (Condition) là một biểu thức Boolean tinh chỉnh khả năng áp dụng của quy tắc ngoài các vị từ được ám chỉ bởi mục tiêu của nó. Do đó, nó có thể vắng mặt.
+ “Biểu thức nghĩa vụ” (ObligationExpressions) là biểu thức mà người viết chính sách có thể thêm các biểu thức nghĩa vụ. Khi PDP đánh giá một chính sách chứa các biểu thức nghĩa vụ, nó sẽ đánh giá các biểu thức nghĩa vụ thành nghĩa vụ và trả lại một số nghĩa vụ đó cho PEP trong ngữ cảnh phản hồi.
+ “Bộ chọn thuộc tính” (AttributeSelector) cho phép chính sách chỉ định một thuộc tính với số nhận dạng, danh mục và kiểu dữ liệu nhất định. Mặt khác, AttributeSelector cung cấp một phương tiện để tra cứu giá trị của các thuộc tính bằng cách sử dụng truy vấn XPath bằng cách chỉ định kiểu dữ liệu và biểu thức XPath. Các bộ chọn thuộc tính sau đó được thực thi dựa trên nội dung XML có thể đã được gửi cùng trong yêu cầu XACML ban đầu.
- Phần tử “chính sách” chứa tập hợp các phần tử “quy tắc” và một thủ tục được chỉ định để kết hợp các kết quả đánh giá của chúng. Đây là đơn vị cơ bản của chính sách được PDP sử dụng và vì vậy nó được dùng để tạo cơ sở cho một quyết định ủy quyền.
- Phần tử "bộ chính sách” chứa tập hợp các phần tử “chính sách” hoặc các phần tử “bộ chính sách” khác và một quy trình cụ thể để kết hợp các kết quả đánh giá của chúng. Nó là phương tiện tiêu chuẩn để kết hợp các chính sách riêng biệt thành một chính sách kết hợp duy nhất.
Hình 2: một mẫu chính sách XACML v3.0
Thuộc tính là định nghĩa biểu thị tất cả chủ thể, tài nguyên, môi trường và hành động được sử dụng trong chính sách XACML. Trong đó, chủ thể (access-subject) là thực thể yêu cầu quyền truy cập, tài nguyên có thể là một dịch vụ, dữ liệu hoặc một thành phần hệ thống, một hành động (action-ID) đề cập đến loại quyền truy cập được yêu cầu và môi trường đề cập đến một yếu tố có thể cung cấp thông tin bổ sung nếu cần thiết.
Thuật toán kết hợp chính sách
Có các thuật toán kết hợp chính sách được sử dụng bởi Bộ chính sách và các thuật toán kết hợp quy tắc được sử dụng bởi các chính sách. Mỗi thuật toán được đề cập bên dưới có thuật toán Kết hợp Chính sách và các thuật toán Kết hợp Quy tắc của nó. Các thuật toán kết hợp tiêu chuẩn được xác định trong XACML 3.0 như sau:
Công cụ tìm thuộc tính carbon
Công cụ tìm kiếm thuộc tính carbon là Mô-đun này giúp tìm thuộc tính còn thiếu cho một yêu cầu XACML nhất định. Có thể cắm bất kỳ số lượng mô-đun công cụ tìm thuộc tính PIP nào với công cụ tìm thuộc tính Carbon. Bạn cần triển khai giao diện PIPAttributeFinder để viết một mô-đun mới và đăng ký mô-đun đó bằng cách sử dụng tệp cấu hình Rights.properties. Theo mặc định, WSO2 Identity Server được cung cấp cùng với DefaultAttributeFinder giao tiếp với cửa hàng người dùng cơ bản của Identity Server. Lưu trữ người dùng mặc định của Máy chủ định danh là ApacheDS nơi nó có thể được thay đổi bằng cách sử dụng tệp user-mgt.xml.
Tất cả các mô-đun sẽ được khởi tạo và các id thuộc tính được hỗ trợ được truy xuất cho mỗi mô-đun. Trong thời gian chạy, công cụ tìm thuộc tính Carbon sẽ kiểm tra Id thuộc tính hỗ trợ và chuyển nó cho mô-đun thích hợp để xử lý. Công cụ tìm thuộc tính Carbon sử dụng máy lưu vào bộ nhớ đệm để lưu các kết quả vào bộ nhớ đệm hoặc bản thân mô-đun công cụ tìm thuộc tính có thể xử lý nó.
Công cụ tìm kiếm tài nguyên carbon
Điều này được sử dụng để truy xuất tài nguyên con hoặc tài nguyên con của một giá trị tài nguyên cấp gốc nhất định. Về cơ bản, nó được sử dụng để đáp ứng yêu cầu của một hồ sơ nhiều quyết định. Việc triển khai cũng giống như mô-đun công cụ tìm thuộc tính PIP. Theo mặc định, WSO2 Identity Server được cung cấp cùng với DefaultResourceFinder (là việc triển khai PIPResourceFinder) giao tiếp với các tài nguyên đăng ký Carbon.
Một số cải thiện của XACML v3.0 so với v2.0
Sau đây là một số cải thiện của phiên bản 3.0 so với 2.0:
- Tùy chỉnh danh mục thuộc tính được xác định trong XACML v3.0 khác với phiên bản v2.0 thì các thuộc tính đã được tổ chức thành chủ đề, tài nguyên, môi trường hoặc hành động.
- Cải tiến trong Obligation là ở trong XACML 2.0, các nghĩa vụ chỉ có thể được thêm vào các chính sách và bộ chính sách. Tuy nhiên, với XACML 3.0, các quy tắc cũng có thể chứa các nghĩa vụ. Gốc của tất cả các chính sách XACML là một chính sách hoặc một bộ chính sách. Một chính sách đại diện cho một chính sách kiểm soát truy cập duy nhất, được thể hiện thông qua một tập hợp các quy tắc.  Bộ chính sách là một vùng chứa có thể chứa các chính sách hoặc bộ chính sách khác, cũng như các tham chiếu đến các chính sách được tìm thấy ở các vị trí từ xa.
- Lời khuyên (Advice) là một tính năng mới được giới thiệu với XACML 3.0. Lời khuyên tương tự như nghĩa vụ và nó chia sẻ phần lớn cú pháp của nó. Sự khác biệt là theo hợp đồng là PEP có thể bỏ qua bất kỳ lời khuyên nào mà PEP nhận được. Các PEP không phải tuân thủ các tuyên bố tư vấn; PEP có thể xem xét hoặc hủy bỏ tuyên bố. Đặc tả XACML cho biết rằng bất kỳ lời khuyên nào được trả lại cùng với một quyết định đều có thể bị các PEP tuân thủ bỏ qua một cách an toàn. Điều này có nghĩa là các PEP sẽ hoạt động như được mô tả trong phần trước, bất kể PEP làm gì với lời khuyên mà nó có thể nhận được. Ví dụ: PEP phải cho phép truy cập nếu nó nhận được quyết định Cấp phép mà không có nghĩa vụ nào, bất kể lời khuyên nào trong quyết định.
- Cải tiến trong “mục tiêu” là có thể xác định các danh mục thuộc tính tùy chỉnh, nên có những cải tiến trong một số yếu tố liên quan trong chính sách XACML 3.0 khi so sánh với 2.0. Với XACML 3.0, “mục tiêu” phần tử có thể được sử dụng để xác định logic ủy quyền phức tạp hơn trong chính nó khi so sánh với 2.0. Trong XACML 2.0, Target phần tử chứa mối quan hệ OR và AND giữa cùng một danh mục. Tuy nhiên, trong XACML 3.0, AllOf và AnyOf các phần tử đã được đưa vào Target phần tử. Điều đó rõ ràng giúp xác định mối quan hệ OR và AND giữa các danh mục khác nhau.
- Cải tiến trong XPath là tạo ra kiểu dữ liệu XPath mới được giới thiệu với XACML 3.0. Trong XACML 2.0, XPath được định nghĩa là một Chuỗi và không thể xác định ngữ cảnh mà tiền tố không gian tên sẽ giải quyết. Ngoài ra, lược đồ đa quyết định dựa trên XPath cũng được giới thiệu với XACML 3.0.
- Cải tiến trong Yêu cầu và phản hồi XACML là có thể xác định các danh mục thuộc tính tùy chỉnh. Nhiều loại danh mục thuộc tính có thể có trong yêu cầu XACML 3.0.
Trong bài viết này, tiêu chuẩn ngôn ngữ đánh dấu kiểm soát truy cập được giới thiệu một cách khái quát đến cụ thể các cải thiện của phiên bản mới nhất 3.0 để người đọc có hình dung về định dạng ngôn ngữ XACML. Nếu trước kia, XACML không phải là ngôn ngữ chung để thể hiện chính sách bảo mật cũng như chưa được ưa chuộng thì năm gần đây với các cập nhật bổ sung và sự đa dạng của các ngôn ngữ máy khiến cho việc lựa chọn XACML cho việc thống nhất bảo mật và xác định quyền truy cập tích hợp các ngôn ngữ.
Thông qua việc giới thiệu tiêu chuẩn này, bài đọc đưa ra các cơ sở tri thức để áp dụng phát triển ngôn ngữ chung hiệu để thể hiện chính sách bảo mật phục vụ các ứng dụng nghiệp vụ, chuyên môn trong chính phủ điện tử hiện nay. Trong bối cảnh hiện nay của Việt Nam, việc tích hợp và chia sẻ dữ liệu được ưu tiên hàng đầu nhằm phục vụ người dân, cơ quan nhà nước, đồng thời là chìa khóa phát triển chính phủ điện tử Việt Nam, vì vậy việc đưa vào ứng dụng thực tiễn tiêu chuẩn này là vô cùng thiết thực.
Vũ Cao Minh Đức
Tài liệu tham khảo
RFC 7061: “eXtensible Access Control Markup Language (XACML) XML Media Type”, IETF, ISSN: 2070-1721, R. Sinnema, E. Wilde, EMC Corporation, November 2013.
eXtensible Access Control Markup Language (XACML) Version 3.0, OASIS Standard, 22 January 2013
Quản trị viên, Cục Tin Học Hóa
Lần xem: 418 Go top
Giới thiệu giao thức truyền thông điệp/giao tiếp nâng cao AMQP ( 08/12/2021)
Giới thiệu tiêu chuẩn mật khẩu dùng một lần HOTP và TOTP ( 08/12/2021)
Giới thiệu các chuẩn giao tiếp trên thiết bị IoT phần II ( 08/12/2021)
Giới thiệu tiêu chuẩn Mạng cục bộ không dây IEEE 802.11ax ( 07/12/2021)
Giới thiệu một số chuẩn khuôn dạng chữ ký số ( 07/12/2021)
Sự kiện nổi bật
Bộ Thông tin và Truyền thông thông báo kết quả đánh giá chuyển đổi số cấp bộ, cấp tỉnh năm 2020 (DTI)
Đẩy mạnh triển khai Kế hoạch cung cấp 100% DVCTT mức độ đủ điều kiện trong năm 2021
Phê duyệt Chiến lược phát triển Chính phủ điện tử hướng tới Chính phủ số giai đoạn 2021-2025, định hướng đến năm 2030
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử 6 tháng đầu năm 2020 (Công văn số 1735/BTTTT-THH ngày 12 tháng 5 năm 2020)
Nghị định về quản lý, kết nối, chia sẻ dữ liệu số của cơ quan nhà nước.
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử quý I năm 2020 (Công văn số 634/BTTTT-THH ngày 27 tháng 02 năm 2020)
Bộ Thông tin và Truyền thông: ban hành Khung Kiến trúc Chính phủ điện tử Việt Nam, phiên bản 2.0
BỘ THÔNG TIN VÀ TRUYỀN THÔNG: YÊU CẦU BÁO CÁO SỐ LIỆU VỀ PHÁT TRIỂN CHÍNH PHỦ ĐIỆN TỬ QUÝ IV/2019 (CÔNG VĂN SỐ 4045/BTTTT-THH NGÀY 13 THÁNG 11 NĂM 2019)
Bộ Thông tin và Truyền thông: Hướng dẫn các Bộ, ngành, địa phương xây dựng Kế hoạch ứng dụng CNTT trong hoạt động của CQNN năm 2020
Bộ Thông tin và Truyền thông: Ban hành Khung tham chiếu ICT phát triển đô thị thông minh
Ý kiến về Trang thông tin điện tử Cục Tin học hóa?
1. Đạt yêu cầu, 1180 phiếu (88 %)
2. Chưa đạt yêu cầu, 107 phiếu (8 %)
3. Cần thêm chủ đề, 57 phiếu (4 %)
Tổng số phiếu: 1344
THÔNG KÊ TRUY CẬP
Tổng lượt truy cập: 18945337
Người chịu trách nhiệm: Đỗ Công Anh
Chức vụ: Cục trưởng
Trụ sở chính: Tầng 21, Tòa nhà Cục Viễn thông, số 68 đường Dương Đình Nghệ, Yên Hòa, Cầu Giấy, Hà Nội.
Điện thoại: 024.37821766 Fax: 024.35378208
Ghi rõ nguồn "Trang thông tin điện tử Cục Tin học hóa" hoặc "www.aita.gov.vn" khi bạn phát hành lại thông tin từ Website này.


vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en fr vi sv en vi sv ko vi en en en en en en fi sv vi fi en vi en en en fi fr vi fi en vi fi en vi vi vi vi vi vi vi vi vi en vi vi vi vi vi vi vi vi vi vi vi vi en fr fr en en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi nb vi vi vi

--Liên kết-- Chính phủ CIO Trung tâm chính phủ điện tử vietnamnet.vn ĐCS Việt Nam TP Hồ Chí Minh Đài tiếng nói Việt Nam Thủ đô Hà Nội Tập chí ĐCS Quốc Hội TP Đà Nẵng Thừa Thiên Huế TP Hải Phòng An Giang Bà Rịa - Vũng Tàu Bắc Ninh Bình Dương Binh Phước Bình Thuận Cà Mau Cần thơ
TÀI LIỆU - BÁO CÁO
Tiêu chuẩn OpenAPI phiên bản 3.0.3 (OpenAPI Specification version 3.0.3) - Phần I
Ngày nay, các nhà phát triển đã nhận ra rằng việc lãng phí thời gian và công sức vào thiết kế lại như nền tảng, giao diện hay ngôn ngữ mà các công ty khác đã xây dựng là không nên. Thay vào đó, từ các API có sẵn mà có thể lấy ví dụ cụ thể của các nhà cung cấp nền tảng hàng đầu như Salesforce, Amazon, Google, … các lập trình viên và các bên hợp tác có thể dễ dàng phát triển cái mới.
Với OpenAPI, thay vì các phần tử XML, bạn có một tập hợp các đối tượng JSON, với một lược đồ cụ thể xác định cách đặt tên, thứ tự và nội dung của chúng. Tệp JSON này (thường được thể hiện bằng YAML thay vì JSON) mô tả từng phần trong API của người dùng. Bằng cách mô tả API của người dùng ở định dạng tiêu chuẩn, các công cụ xuất bản có thể phân tích cú pháp theo chương trình thông tin về API và hiển thị từng thành phần trong một màn hình tương tác, cách điệu.
Hình 1: Giới thiệu về OpenAPI
Đặc tả OpenAPI Specification 3.0.3 (OAS) xác định một giao diện chuẩn, không có ngôn ngữ cho các API RESTful cho phép cả người và máy tính khám phá và hiểu các khả năng của dịch vụ mà không cần truy cập vào mã nguồn, tài liệu hoặc thông qua kiểm tra lưu lượng mạng. Khi được xác định đúng, người dùng có thể hiểu và tương tác với dịch vụ từ xa với một lượng logic triển khai tối thiểu. Sau đó, định nghĩa OpenAPI có thể được sử dụng bởi các công cụ tạo tài liệu để hiển thị API, các công cụ tạo mã để tạo máy chủ và máy khách bằng các ngôn ngữ lập trình khác nhau, công cụ kiểm tra và nhiều trường hợp sử dụng khác.
OAS được xây dựng dựa trên bộ mã nguồn mở Swagger vào cuối năm 2015 và cho ra đời bản thảo đầu tiên vào 28.02.2017. Đến 26.06.2017, đặc tả OpenAPI phiên bản 3.0.0 đầu tiên được phát hành và được triển khai rộng rãi trên môi trường mạng. Phiên bản hiện tại OpenAPI Specification 3.0.3 là phiên bản vá lỗi và hoạn thiện cuối cùng của đặc tả này vào ngày 20.02.2020.
Hình 2: Giao diện viết API
Các giá trị từ OAS
Sau một thời gian dài được tung lên môi trường mạng từ thời điểm năm 2017 và qua các bản vá lỗi, OAS đã chứng minh được các giá trị về nhiều mặt lợi ích:
- Phát triển sản phẩm được rút ngắn thời gian:
Thế giới đang chứng kiến được sự mạnh mẽ phát triển của lĩnh vực Open API. Một trong những cái tên đáng chú ý có thể kể đến ProgrammableWeb với việc chia sẻ kho 15.000 API của mình. Người dùng hay lập trình viên có thể dễ dàng thấy các API mới được cập nhật mỗi ngày. Các lập trình viên có thể chèn các đoạn mã API này vào các dự án phần mềm họ đang thực hiện và tung sản phẩm ra thị trường nhanh chóng hơn. Việc thiết kế các phần nhỏ, tiểu tiết của sản phẩm tổng thể đã được thay thế bởi các đoạn mã API. Một số nhà cung cấp dịch vụ khác lại chọn hướng phát triển chuyên sâu hướng tới nhóm đối tượng hay khách hàng cụ thể, điều đó khiến giá trị sản phẩm API của họ cao hơn và họ cũng không mất nhiều thời gian để làm một sản phẩm tổng thể.
- Hướng tới cốt lõi của sản phẩm:
Ngoài lợi ích về việc giúp các lập trình viên hoàn thiện sản phẩm nhanh chóng, OAS có một lợi ích to lớn khác chính là giúp các nhà phát triển, các lập trình viên tập trung vào chất riêng cho sản phẩm của họ, điều này là bởi OAS giúp họ giảm bớt các phần “râu ria” đi kèm với sản phẩm mà vẫn đúng theo mong muốn của họ.
- Các sản phẩm API sẽ ngày một chất lượng hơn trước:
Nhiều API hoạt động hiệu quả và linh hoạt hơn các API khác, những API kém hiệu quả hơn thường là do bị bó buộc vào yêu cầu sản phẩm trong nội bộ công ty. Trong khi đó, các API phát triển bởi “bên thứ ba” với mục tiêu hướng tới nhiều hiệu năng, thân thiện người dùng hơn lại được ưa chuộng hơn. Các công ty thường coi nhẹ khâu xây dựng và bảo trì các tính năng họ có thể chèn vào sản phẩm của mình bằng các Open API. Cuối cùng thì các nhà cung cấp Open API “bên thứ ba” lại thu hút người sử dụng nhiều hơn, mặt khác họ thu được một khối dữ liệu lớn hơn để tạo ra hiệu ứng lan tỏa. (network effect). Những hiệu ứng lan tỏa này có thể là giá thành rẻ hơn, thỏa thuận cung cấp dịch vụ tốt hơn cho đến khả năng sử dụng AI phân tích các loại dữ liệu người dùng. Ví dụ như công ty Signifyd chuyên cung cấp Open API phân tích các hành vi gian lận trong sử dụng sản phẩm mà cụ thể là API này sẽ tổng hợp dữ liệu giao dịch từ hàng trăm công ty, cho phép họ hiểu sâu hành vi của một lượng lớn các vụ gian lận hơn bất cứ một công ty đơn lẻ nào có thể nhìn ra.
Các mô hình kinh doanh và sử dụng OAS phổ biến
Hiện tại có 3 mô hình kinh doanh chính với OAS
- Cung cấp API hoàn toàn miễn phí:
Việc cung cấp API miễn phí có nhiều mục đích nhưng về cơ bản nó giúp việc quảng bá rộng dãi API một cách nhanh chóng mà hiệu quả hơn việc trả tiền quảng cáo hay chờ tính quen thuộc với người dùng. Ví dụ là Facebook cho phép nhúng nút “like” vào các trang web khác. Điều này giúp nút Like của Facebook lan tỏa khắp nơi trên Internet, khẳng định nền tảng “social networking” số một thế giới của Facebook.
- Trả tiền để sử dụng:
Đơn giản như cách gọi của nó, người dùng cần trả tiền tiền để được sử dụng các dịch vụ của bên cung cấp API. Tuy nhiên, kinh doanh từ API là một mô hình kinh doanh số tiềm năng có từ thời điểm 2016, dưới đây là một số mô hình nổi bật
+ “Pay As You Go”: Được hiểu là trả tiền theo nhu cầu thực tế sử dụng. Điển hình cho mô hình này là dịch vụ Cloud của Amazon, đó là Amazon Web Services (AWS). AWS cung cấp các dịch vụ cơ sở hạ tầng như máy chủ, cơ sở dữ liệu, lưu trữ, hạ tầng mạng... với chính sách giá Pay-As-You-Go. Các dịch vụ của AWS không có mức chi phí tối thiểu, cũng không cần phải cọc trước hay hợp đồng dài hạn. Tất cả phụ thuộc vào người dùng, trả phí theo đúng thời gian sử dụng thực tế. Nhìn nhận về việc cho thuê hạ tầng máy chủ với các hệ thống cũ, việc mua và lắp đặt hệ thống mất rất nhiều thời gian, dẫn đến việc các tài nguyên phải được mua trước theo dự báo nhu cầu, việc đó dẫn đến tổ chức phải bỏ ra một số vốn lớn ban đầu (capex), và gây lãng phí hoặc nếu không thì lại không đáp ứng được nhu cầu thật. Từ những lợi ích và tiện lợi của AWS, rất nhiều công ty lớn đã sử dụng AWS thay vì phát triển hệ thống cơ sở hạ tầng của mình hoặc thuê các loại hình trung tâm dữ liệu truyền thống, nó quá tiện lợi và giảm thiểu chi phí. Một ví dụ cụ thể là Netflix, một công ty cung cấp dịch vụ xem phim trực tuyến lớn nhất thế giới. Netflix đã sử dụng AWS cho gần như toàn bộ hệ thống streaming của họ, Netflix sử dụng hàng chục nghìn máy chủ và lưu trữ hàng chục petabytes dữ liệu trên dịch vụ AWS bởi yếu tố linh hoạt trong quản trị và giá thành tổ chức với phương thức tính giá mới này.
+ “Freemium”: Được hiểu là miễn phí tính năng cơ bản, trả tiền cho tính năng cao cấp. Với mô hình này, người dùng được dùng miễn phí sản phẩm và dịch vụ được coi là cơ bản nhất của ứng dụng, điều này giúp xây dựng thói quen sử dụng ứng dụng ở khách hàng, phí chỉ được tính khi khách hàng muốn sử dụng các tính năng mở rộng hay đặc biệt hơn. Đây cũng là một mô hình thông dụng mà nhiều nhà cung cấp API thương mại hay sử dụng. Mô hình hình có một lợi thế lớn là dễ dàng tiếp cận tập người dùng có nhu cầu cơ bản, kích thích thói quen sử dụng để thu thập dữ liệu người dùng rồi từ đó xây dựng các tính năng tích hợp mở rộng có sức hút hơn. Các dịch vụ cao cấp cũng nhờ thế mà có thể có một số nhỏ người dùng trả tiền hay nhóm người dùng doanh nghiệp tổ chức khi tập người dùng đã trở nên đủ nhiều và đa dạng. Ví dụ, dịch vụ Google Cloud Vision API cho phép người dùng sử dụng miễn phí 1.000 unit/tháng; hoặc dịch vụ Google Maps API cũng dùng chính sách freemium.
+ Ngoài ra còn rất nhiều mô hình khác như: transaction fee, unit-based, …
- Được trả tiền khi sử dụng:
Đối với mô hình này, chủ yếu là tạo ra lợi ích cho bên cung cấp API. Vì vậy, nhà cung cấp muốn khuyến khích và tạo động lực cho việc sử dụng API của họ một cách cởi mở là trả tiền cho người dùng. Còn các hình thức trả phí cho nhà phát triển rất đa dạng tùy thuộc vào ngành nghề và phương pháp kinh doanh của từng nhà cung cấp.
Trên thế giới hiện nay thì có khá nhiều API trả tiền nhưng nổi tiếng nhất trong những API trả tiền là Amazon Advertising API. API này cho phép nhà phát triển truy cập và lấy thông tin về hàng triệu sản phẩm mà Amazon đang bán trên hệ thống của họ trên toàn cầu như: Sách báo, âm nhạc, đồ điện tử, đồ gia dụng... Từ đó, nhà phát triển có thể dùng thông tin này để quảng cáo các sản phẩm trên trang web của mình. Nếu người dùng mua một sản phẩm mà do nhà phát triển giới thiệu đến, thì Amazon sẽ trả cho người giới thiệu một tỷ lệ hoa hồng quảng cáo nhất định tùy theo mặt hàng. Những hình thức này người ta gọi là tiếp thị liên kết (affiliate marketing). Đây là phương thức tiếp thị dựa trên nền tảng công nghệ Internet; so với cách quảng cáo truyền thống cần đăng ký và cọc trước tiền quảng cáo hay thành công nằm ở tần xuất và ảnh hưởng của quảng cáo thì cách tiếp thị mới tạo ra một cách tiếp cận hiệu quả hơn và hợp lí hơn. Các bên liên kết với nhau dựa trên nền tảng API để tiếp thị cho sản phẩm.
Nội dung chi tiết
OAS là một định dạng mô tả API dành cho REST APIs. Một tệp OpenAPI cho phép người dùng mô tả toàn bộ API bao gồm:
- Cho phép những endpoints (/users) và cách thức hoạt động của mỗi endpoint (GET /users, POST /users)
- Các tham số đầu vào và ra của từng hoạt động
- Phương thức xác thực
- Thông tin liên lạc, chứng chỉ, điều khoản sử dụng và những thông tin khác
OAS cần tạo mẫu đường dẫn đề cập đến việc sử dụng các biểu thức mẫu, được phân tách bằng dấu ngoặc nhọn ({}) để đánh đấu một phần của đường dẫn URL là có thể thay thế bằng cách sử dụng các tham số đường dẫn.
Đối với các tiêu chuẩn kết nối, OAS tuân thủ RFC6838. Đối với mã trạng thái HTTP, nó được sử dụng để chỉ ra trạng thái của hoạt động được thực thi. Các mã trạng thái có sẵn được xác định bởi RFC7231 và các mã trạng thái đã đăng ký được liệt kê theo tổ chức cấp phát số hiệu chuẩn Internet (IANA).
Bản thân tài liệu OpenAPI tuân theo Đặc điểm kỹ thuật OpenAPI là một đối tượng JSON, có thể được biểu diễn ở định dạng JSON hoặc YAML.
Ví dụ: nếu một trường có giá trị mảng, thì biểu diễn mảng JSON sẽ được sử dụng:
Hình 3: Mảng JSON theo OAS
Tất cả các tên trường trong đặc tả đều phân biệt chữ hoa chữ thường. Điều này bao gồm tất cả các trường được sử dụng làm khóa trong miêu tả, ngoại trừ trường hợp được ghi chú rõ ràng rằng các khóa không phân biệt chữ hoa chữ thường.
Lược đồ hiển thị hai loại trường: trường cố định, có tên được khai báo và trường có mẫu, khai báo mẫu regex cho tên trường.
Các trường có mẫu phải có tên duy nhất với đối tượng mà nó đại diện.
Để duy trì khả năng thay đổi giữa các định dạng YAML và JSON, YAML phiên bản 1.2 được khuyến cáo cùng với một số ràng buộc bổ sung:
- Các thẻ phải được giới hạn ở những thẻ được bộ quy tắc lược đồ JSON cho phép .
- Các khóa được sử dụng trong bản đồ YAML phải được giới hạn trong một chuỗi vô hướng, như được định nghĩa bởi bộ quy tắc lược đồ YAML Failsafe.
Khuyến cáo rằng tài liệu OpenAPI gốc phải được đặt tên: openapi.json hoặc openapi.yaml.
Lưu ý: Mặc dù các API có thể được định nghĩa bởi các tài liệu OpenAPI ở định dạng YAML hoặc JSON, các cơ quan phản hồi và yêu cầu API cũng như nội dung khác không bắt buộc phải là JSON hoặc YAML.
3. Các loại dữ liệu
Các kiểu dữ liệu ban đầu trong OAS dựa trên các kiểu được hỗ trợ bởi Bản thảo Wright của lược đồ JSON (JSON Schema: A Media Type for Describing JSON Documents draft-wright-json-schema-00). Lưu ý rằng integer với tư cách là một loại cũng được hỗ trợ và được định nghĩa là số JSON không có phần phân số hoặc số mũ. nullkhông được hỗ trợ như một loại (xem nullablegiải pháp thay thế). Mô hình được định nghĩa bằng Đối tượng lược đồ, là một tập con mở rộng của Đặc tả lược đồ JSON Wright Draft 00.
Primitives có một định dạng sửa đổi tùy chọn: “format”. OAS sử dụng một số định dạng đã biết để xác định chi tiết kiểu dữ liệu đang được sử dụng. Tuy nhiên, để hỗ trợ nhu cầu tài liệu, “format” định dạng là định dạng được “string” miêu tả mở và có thể có bất kỳ giá trị nào.
Các định dạng chẳng hạn như "email", "uuid"v.v., có thể được sử dụng mặc dù không được xác định bởi đặc tả này. Các kiểu không kèm theo thuộc “format” tính tuân theo định nghĩa kiểu trong Lược đồ JSON. Các công cụ không nhận ra một cụ thể “format” có thể mặc định trở lại “type” một mình, như một “format” ở thể không được chỉ định.
Các định dạng được xác dịnh bởi OAS là:
Ký ở định dạng 32 bit
Ký ở định đạng 64 bit (có thể gọi là “long”)
Ký tự được mã hóa base64
Bất kỳ chuỗi octet nào
Theo định nghĩa “full-date” thuộc RFC3339
Theo định nghĩa “date-time” thuộc RFC3339
Một gợi ý cho giao diện người dùng để che khuất đầu nhập vào.
4. Định dạng văn bản đa dạng thức
Trong suốt các trường thông số kỹ thuật, “description" được ghi nhận là hỗ trợ định dạng đánh dấu CommonMark. Trường hợp công cụ OpenAPI hiển thị văn bản đa dạng thức thì nó phải hỗ trợ, ở mức tối thiểu, cú pháp đánh dấu như được mô tả bởi CommonMark 0.27. Việc xây dựng API có thể chọn bỏ qua một số tính năng CommonMark để giải quyết các mối lo ngại về bảo mật.
5. Phần mở rộng đặc điểm
Trong khi Đặc điểm kỹ thuật OpenAPI cố gắng đáp ứng hầu hết các trường hợp sử dụng, dữ liệu bổ sung có thể được thêm vào để mở rộng thông số kỹ thuật tại một số điểm nhất định.
Các thuộc tính tiện ích mở rộng được triển khai dưới dạng các trường mẫu luôn có tiền tố là "x-".
Cho phép các phần mở rộng cho lược đồ OpenAPI. x-Ví dụ: tên trường phải bắt đầu bằng x-internal-id. Giá trị có thể là null, một nguyên thủy, một mảng hoặc một đối tượng. Có thể có bất kỳ giá trị định dạng JSON hợp lệ nào.
6. Bảo mật với yếu tố lọc bỏ
Một số đối tượng trong Đặc tả OpenAPI có thể được khai báo và vẫn trống hoặc bị loại bỏ hoàn toàn, mặc dù chúng vốn dĩ là cốt lõi của tài liệu API.
Lý do là để cho phép một lớp kiểm soát truy cập bổ sung đối với tài liệu. Mặc dù không phải là một phần của bản đặc tả, nhưng một số thư viện có thể chọn cho phép truy cập vào các phần của tài liệu dựa trên một số hình thức xác thực / ủy quyền.
Hai ví dụ về điều này:
- Các Paths Object có thể rỗng. Nó có thể phản trực giác, nhưng điều này có thể cho người xem biết rằng họ đã đến đúng nơi, nhưng không thể truy cập bất kỳ tài liệu nào. Họ vẫn có quyền truy cập vào đối tượng thông tin có thể chứa thông tin bổ sung về xác thực.
- Các đường dẫn mục Object có thể rỗng. Trong trường hợp này, người xem sẽ biết rằng đường dẫn tồn tại, nhưng sẽ không thể thấy bất kỳ hoạt động hoặc tham số nào của nó. Điều này khác với việc ẩn chính đường dẫn khỏi đối tượng đường dẫn, bởi vì người dùng sẽ nhận thức được sự tồn tại của nó. Điều này cho phép nhà cung cấp tài liệu kiểm soát tốt những gì người xem có thể nhìn thấy.
Như vậy, phần một của tiêu chuẩn OpenAPI phiên bản 3.0.3 đã chỉ ra những nét cơ bản nhất, các khái niệm của tiêu chuẩn này, đồng thời chia sẻ về tính ứng dụng và hiệu quả của tiêu chuẩn mang tính thực tiễn cao cho người sử dụng cả về mặt kinh tế và hiệu năng sử dụng. Phần tiếp theo sẽ đi sâu vào chia tiết các đối tượng của tiêu chuẩn này.
Vũ Cao Minh Đức
Tài liệu tham khảo
Quản trị viên, Cục Tin Học Hóa
Lần xem: 4785 Go top
Giới thiệu giao thức truyền thông điệp/giao tiếp nâng cao AMQP ( 08/12/2021)
Giới thiệu tiêu chuẩn mật khẩu dùng một lần HOTP và TOTP ( 08/12/2021)
Giới thiệu các chuẩn giao tiếp trên thiết bị IoT phần II ( 08/12/2021)
Giới thiệu tiêu chuẩn Mạng cục bộ không dây IEEE 802.11ax ( 07/12/2021)
Giới thiệu một số chuẩn khuôn dạng chữ ký số ( 07/12/2021)
Sự kiện nổi bật
Bộ Thông tin và Truyền thông thông báo kết quả đánh giá chuyển đổi số cấp bộ, cấp tỉnh năm 2020 (DTI)
Đẩy mạnh triển khai Kế hoạch cung cấp 100% DVCTT mức độ đủ điều kiện trong năm 2021
Phê duyệt Chiến lược phát triển Chính phủ điện tử hướng tới Chính phủ số giai đoạn 2021-2025, định hướng đến năm 2030
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử 6 tháng đầu năm 2020 (Công văn số 1735/BTTTT-THH ngày 12 tháng 5 năm 2020)
Nghị định về quản lý, kết nối, chia sẻ dữ liệu số của cơ quan nhà nước.
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử quý I năm 2020 (Công văn số 634/BTTTT-THH ngày 27 tháng 02 năm 2020)
Bộ Thông tin và Truyền thông: ban hành Khung Kiến trúc Chính phủ điện tử Việt Nam, phiên bản 2.0
BỘ THÔNG TIN VÀ TRUYỀN THÔNG: YÊU CẦU BÁO CÁO SỐ LIỆU VỀ PHÁT TRIỂN CHÍNH PHỦ ĐIỆN TỬ QUÝ IV/2019 (CÔNG VĂN SỐ 4045/BTTTT-THH NGÀY 13 THÁNG 11 NĂM 2019)
Bộ Thông tin và Truyền thông: Hướng dẫn các Bộ, ngành, địa phương xây dựng Kế hoạch ứng dụng CNTT trong hoạt động của CQNN năm 2020
Bộ Thông tin và Truyền thông: Ban hành Khung tham chiếu ICT phát triển đô thị thông minh
Ý kiến về Trang thông tin điện tử Cục Tin học hóa?
1. Đạt yêu cầu, 1180 phiếu (88 %)
2. Chưa đạt yêu cầu, 107 phiếu (8 %)
3. Cần thêm chủ đề, 57 phiếu (4 %)
Tổng số phiếu: 1344
THÔNG KÊ TRUY CẬP
Tổng lượt truy cập: 18945524
Người chịu trách nhiệm: Đỗ Công Anh
Chức vụ: Cục trưởng
Trụ sở chính: Tầng 21, Tòa nhà Cục Viễn thông, số 68 đường Dương Đình Nghệ, Yên Hòa, Cầu Giấy, Hà Nội.
Điện thoại: 024.37821766 Fax: 024.35378208
Ghi rõ nguồn "Trang thông tin điện tử Cục Tin học hóa" hoặc "www.aita.gov.vn" khi bạn phát hành lại thông tin từ Website này.


vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi nb vi vi vi

Bộ Thông tin và Truyền thông
Các đơn vị trực thuộc
Tin tức - Sự kiện
Ứng dụng CNTT trong Cơ quan nhà nước
Nghiên cứu - đánh giá
Thống kê - báo cáo
Xin ý kiến dự thảo văn bản
Dữ liệu đa phương tiện
--Liên kết-- Chính phủ CIO Trung tâm chính phủ điện tử vietnamnet.vn ĐCS Việt Nam TP Hồ Chí Minh Đài tiếng nói Việt Nam Thủ đô Hà Nội Tập chí ĐCS Quốc Hội TP Đà Nẵng Thừa Thiên Huế TP Hải Phòng An Giang Bà Rịa - Vũng Tàu Bắc Ninh Bình Dương Binh Phước Bình Thuận Cà Mau Cần thơ
TÀI LIỆU - BÁO CÁO
Danh mục điện tử dùng chung của các cơ quan nhà nước phục vụ phát triển Chính phủ điện tử tại Việt Nam (14/04/2020)
Bộ TT&TT: Triển khai QCVN số 102:2016/BTTTT về cấu trúc mã định danh và định dạng dữ liệu gói tin phục vụ kết nối các hệ thống văn bản quản lý và điều hành (Cập nhật ngày 21/5/2018) (13/09/2016)
Bộ Thông tin và Truyền thông: Giải thích các tiêu chuẩn kỹ thuật về ứng dụng CNTT trong cơ quan nhà nước (Cập nhật ngày 24/8/2017) (21/11/2013)
Xem tất cả »
Cục Tin học hóa > Tin tức - sự kiện > Thông tin tổng hợp
Chính phủ ban hành Nghị định số 42/2022/NĐ-CP Quy định về việc cung cấp thông tin và dịch vụ công trực tuyến của cơ quan nhà nước trên môi trường mạng
Ngày 24 tháng 6 năm 2022, Chính phủ ban hành Nghị định số 42/2022/NĐ-CP Quy định về việc cung cấp thông tin và dịch vụ công trực tuyến của cơ quan nhà nước trên môi trường mạng...
Ngày đăng : 27/06/2022    Xem với cỡ chữ
Nghị định số 42/2022/NĐ-CP quy định về việc cung cấp thông tin và dịch vụ công trực tuyến của cơ quan nhà nước trên môi trường mạng. Nghị định này thay thế Nghị định số 43/2011/NĐ-CP ngày 13/6/2011 quy định về việc cung cấp thông tin và dịch vụ công trực tuyến trên trang thông tin điện tử hoặc cổng thông tin điện tử của cơ quan nhà nước. Như vậy, sau 11 năm thi hành, Nghị định số 43/2011/NĐ-CP đã được thay thế bằng Nghị định số 42/2022/NĐ-CP với các nội hàm quản lý mới, phù hợp với thực tiễn và xu thế phát triển của ứng dụng công nghệ thông tin, chuyển đổi số.
Một số chính sách mới của Nghị định số 42/2022/NĐ-CP ngày 24/6/2022:
Về cung cấp thông tin:
a) Trang thông tin điện tử hoặc cổng thông tin điện tử của cơ quan nhà nước (sau đây gọi chung là cổng thông tin điện tử của cơ quan nhà nước) là kênh cung cấp thông tin thống nhất, tập trung của cơ quan nhà nước trên môi trường mạng.
Theo đó, mỗi bộ, cơ quan ngang bộ, cơ quan thuộc Chính phủ, Ủy ban nhân dân tỉnh, thành phố trực thuộc trung ương có một và chỉ một cổng thông tin điện tử là kênh cung cấp thông tin chính thống, tập trung của cơ quan nhà nước trong phạm vi bộ, ngành, địa phương trên môi trường mạng. Các đơn vị thuộc, trực thuộc nếu có trang thông tin điện tử thì phải là thành phần của Cổng thông tin điện tử của bộ, cơ quan ngang bộ, cơ quan thuộc Chính phủ, Ủy ban nhân dân tỉnh, thành phố trực thuộc trung ương.
Tên miền truy cập cổng thông tin điện tử của cơ quan nhà nước sử dụng tên miền quốc gia Việt Nam “.vn” (được quy định đến tận cấp xã) và sử dụng công nghệ địa chỉ Internet IPv6.
Thời gian chuyển tiếp 2 năm nếu như hiện tại các trang thông tin điện tử của cơ quan nhà nước trực thuộc bộ, cơ quan ngang bộ, cơ quan thuộc Chính phủ; cơ quan chuyên môn thuộc Ủy ban nhân dân tỉnh, thành phố trực thuộc trung ương; Ủy ban nhân dân cấp huyện; Ủy ban nhân dân cấp xã chưa tuân thủ theo quy định của Nghị định này.
b) Ngoài cổng thông tin điện tử, cơ quan nhà nước có thể triển khai các kênh cung cấp thông tin khác để cung cấp thông tin cho người dân, doanh nghiệp như: Cổng dữ liệu cấp bộ, cấp tỉnh; Mạng xã hội; Ứng dụng trên thiết bị di động; Tổng đài điện thoại; Thư điện tử (Email).
Các kênh cung cấp thông tin cho người dân phải đáp ứng các yêu cầu về sự thuận tiện, an toàn thông tin mạng và cho phép người dân đánh giá mức độ hài lòng về thông tin được cung cấp… Các kênh này phải được kết nối, tích hợp để bảo đảm cung cấp thông tin đồng bộ với thông tin trên cổng thông tin điện tử của cơ quan nhà nước.
Việc kết nối, chia sẻ dữ liệu giữa các cơ quan nhà nước thực hiện theo quy định tại Nghị định số 47/2020/NĐ-CP ngày 09/4/2020 của Chính phủ quản lý, kết nối và chia sẻ dữ liệu số của cơ quan nhà nước.
c) Thông tin cung cấp trên môi trường mạng của cơ quan nhà nước tuân theo một số văn bản quy phạm pháp luật (ban hành sau Nghị định số 43/2011/NĐ-CP) như Luật Tiếp cận thông tin, Luật Thống kê, Luật Quy hoạch, Luật Khoa học và Công nghệ...
Cơ quan nhà nước có trách nhiệm phân công, bố trí đủ nhân lực biên tập cổng thông tin điện tử, nhân lực quản trị kỹ thuật; bồi dưỡng nhân lực để bảo đảm phục vụ hoạt động cung cấp thông tin và dịch vụ công trực tuyến của cơ quan nhà nước trên môi trường mạng.
d) Việc đo lường, giám sát hiệu quả cung cấp thông tin được thực hiện tự động.
Một trong những đặc trưng của Chính phủ số là khả năng đo lường, giám sát trực tuyến để đưa ra quyết định theo thời gian thực. Do đó, trong Nghị định này, Chính phủ giao Bộ Thông tin và Truyền thông hướng dẫn các bộ, cơ quan ngang bộ, cơ quan thuộc Chính phủ, Ủy ban nhân dân các tỉnh, thành phố trực thuộc trung ương kết nối với Hệ thống giám sát, đo lường mức độ cung cấp và sử dụng dịch vụ Chính phủ số (EMC) để quản lý, giám sát hiệu quả, mức độ cung cấp, sử dụng thông tin của cơ quan nhà nước trên môi trường mạng, tổng hợp, báo cáo Thủ tướng Chính phủ.
Tính đến hiện tại, Bộ Thông tin và Truyền thông đã có văn bản gửi đến các bộ, ngành, địa phương đề nghị kết nối kỹ thuật 03 hệ thống (bao gồm Cổng thông tin điện tử, Cổng dịch vụ công, và Hệ thống Một cửa điện tử) với EMC của Bộ Thông tin và Truyền thông.
Cho đến nay, đã có 27/27 bộ, 63/63 tỉnh, thành phố trực thuộc Trung ương hoàn thành kết nối Cổng thông tin điện tử của bộ, cơ quan ngang bộ, cơ quan thuộc Chính phủ; cơ quan chuyên môn thuộc Ủy ban nhân dân tỉnh, thành phố trực thuộc trung ương với hệ thống EMC để thực hiện đo lường, giám sát tự động việc cung cấp, sử dụng thông tin của cơ quan nhà nước trên môi trường mạng.
Về cung cấp DVCTT:
a) Thay đổi cách thức phân loại mức độ DVCTT
Trước đây, theo Nghị định số 43/2011/NĐ-CP, các DVCTT được phân thành 04 mức độ. Tuy nhiên, trong quá trình triển khai thực tiễn, cách phân loại này chưa thực sự rõ ràng, tương minh, có thể dẫn đến cách hiểu không đồng bộ. Vấn đề này đã được giải quyết trong Nghị định số 42/2022/NĐ-CP. Theo đó, DVCTT được phân ra theo 02 mức: mức trực tuyến một phần và mức trực tuyến toàn trình.
DVCTT toàn trình là dịch vụ bảo đảm cung cấp toàn bộ thông tin về thủ tục hành chính, việc thực hiện và giải quyết thủ tục hành chính đều được thực hiện trên môi trường mạng. Việc trả kết quả được thực hiện trực tuyến hoặc qua dịch vụ bưu chính công ích. DVCTT một phần là DVCTT không bảo đảm các điều kiện của DVCTT toàn trình. Khi đó, cơ quan nhà nước ứng dụng công nghệ thông tin, công nghệ số tối đa trong quá trình cung cấp và xử lý dịch vụ công trực tuyến trên môi trường mạng trừ trường hợp tổ chức, cá nhân sử dụng dịch vụ phải hiện diện tại cơ quan nhà nước hoặc cơ quan nhà nước phải đi thẩm tra, xác minh tại hiện trường theo quy định của pháp luật.
Cách phân loại này đơn giản, tường minh và phù hợp với cách tiếp cận về phân loại DVCTT trên thế giới.
b) Quy định về các kênh cung cấp DVCTT
Cổng dịch vụ công là kênh cung cấp DVCTT bắt buộc. Ngoài ra, căn cứ vào điều kiện cụ thể, các cơ quan nhà nước chủ động triển khai các kênh cung cấp DVCTT khác như: Ứng dụng trên thiết bị di động, Mạng xã hội. Cơ quan nhà nước phải công bố các kênh cung cấp DVCTT. Người dân, doanh nghiệp được lựa chọn kênh sử dụng DVCTT. Các kênh cung cấp DVCTT cho phép tổ chức, cá nhân đánh giá trực tuyến mức độ hài lòng về DVCTT được cung cấp.
Các kênh cung cấp DVCTT phải có giao diện thân thiện, dễ sử dụng, an toàn bảo mật; đáp ứng nhu cầu của tổ chức, cá nhân, đặc biệt, hỗ trợ người khuyết tật tiếp cận, sử dụng.
c) Thực hiện nguyên tắc tổ chức, cá nhân chỉ cung cấp thông tin một lần cho cơ quan nhà nước khi thực hiện dịch vụ công trực tuyến
Để thực hiện nguyên tắc này, quy định cơ quan nhà nước phải kết nối, khai thác dữ liệu từ các cơ sở dữ liệu quốc gia, cơ sở dữ liệu chuyên ngành, cơ sở dữ liệu dùng chung của các cơ quan nhà nước khác để tự động điền các thông tin vào biểu mẫu điện tử và cắt giảm thành phần hồ sơ.
Việc kết nối, chia sẻ dữ liệu giữa các cơ quan nhà nước thực hiện theo quy định tại Nghị định số 47/2020/NĐ-CP ngày 09/4/2020 của Chính phủ quản lý, kết nối và chia sẻ dữ liệu số của cơ quan nhà nước.
d) Chuẩn hóa danh mục DVCTT (mã, tên, e-form, quy trình)
Nghị định số 42/2022/NĐ-CP đã giao Văn phòng Chính phủ xây dựng quy định, hướng dẫn việc chuẩn hóa danh mục DVCTT các cấp và thống nhất trên phạm vi toàn quốc.
đ) Các yêu cầu kỹ thuật cung cấp DVCTT, trong đó nhấn mạnh triển khai dưới dạng dịch vụ;
Việc thiết kế, xây dựng, cung cấp các dịch vụ công trực tuyến tuân thủ các quy chuẩn, quy định kỹ thuật đối với các hệ thống thông tin cung cấp dịch vụ công trực tuyến. Sản phẩm phần mềm cung cấp dịch vụ công trực tuyến được triển khai dưới dạng các dịch vụ để dễ dàng nhân rộng và tuỳ biến, ít đòi hỏi năng lực công nghệ.
e) Đo lường tự động hiệu quả DVCTT, kết nối EMC của Bộ TTTT để thực hiện.
Nghị định này quy định: Việc quản lý, giám sát, đánh giá hiệu quả, mức độ sử dụng dịch vụ công trực tuyến của các cơ quan nhà nước phải được thực hiện tự động hóa bằng hệ thống thông tin với từng dịch vụ công trực tuyến, từng chủ thể tham gia giao dịch, từng bước thực hiện dịch vụ.
Nghị định cũng quy định: bộ, cơ quan ngang bộ, cơ quan thuộc Chính phủ, Ủy ban nhân dân các tỉnh, thành phố trực thuộc trung ương có trách nhiệm kết nối các hệ thống cung cấp dịch vụ công trực tuyến cấp bộ, cấp tỉnh với hệ thống EMC của Bộ Thông tin và Truyền thông để thực hiện đo lường, giám sát, đánh giá hiệu quả cung cấp, sử dụng các DVCTT.
Tác động dự kiến của Nghị định 42/2022/NĐ-CP ngày 24/6/2022 khi được triển khai thực tiễn:
a) Người dân, doanh nghiệp có thể truy cập, sử dụng thông tin và DVCTT của cơ quan nhà nước 24/7, ở bất cứ đâu và lựa chọn kênh cung cấp theo nhu cầu;
b) Người dân, doanh nghiệp được sử dụng DVCTT toàn trình từ đầu đến cuối trên môi trường mạng (với các dịch vụ công cung cấp được toàn trình theo quy định) và hướng tới chỉ cần khai báo thông tin một lần cho cơ quan nhà nước khi sử dụng DVCTT.
c) Cơ quan nhà nước quản lý kênh cung cấp thông tin và DVCTT tập trung, thống nhất (đến tận cấp xã), bảo đảm không chồng chéo, trùng lặp, giúp cơ quan nhà nước tiết kiệm chi phí, nhân lực.
d) Việc cung cấp thông tin và DVCTT tuân thủ theo các tiêu chuẩn, quy chuẩn, hướng dẫn kỹ thuật sẽ bảo đảm khả năng kết nối, tích hợp và chia sẻ dữ liệu, sử dụng lại thông tin, dữ liệu.
đ) Việc đo lường, giám sát tự động hiệu quả cung cấp, sử dụng DVCTT theo thời gian thực sẽ là cách thức giám sát mới, có tính khách quan và hỗ trợ kịp thời cho việc ra quyết định của lãnh đạo các cấp để cải tiến chất lượng, hiệu quả cng cấp, sử dụng thông tin và DVCTT.
e) Việc xây dựng chính sách quản lý, thúc đẩy cung cấp thông tin, cung cấp DVCTT phù hợp với thực tiễn và xu thế phát triển trên thế giới là yêu cầu bắt buộc để nâng cao chất lượng phục vụ người dân, doanh nghiệp và góp phần nâng cao thứ hạng của Việt Nam trong các bảng xếp hạng quốc tế.
Toàn văn Nghị định 42/2022/NĐ-CP được đăng tải tại đây.
Cục Tin học hóa
Quản trị viên, Cục Tin Học Hóa
Lần xem: 117 Go top
Hòa Bình sẽ nâng tỷ lệ hồ sơ giải quyết trực tuyến mức cao lên 55% ( 23/02/2022)
Bộ Thông tin và Truyền thông thông báo kết quả đánh giá chuyển đổi số cấp bộ, cấp tỉnh năm 2020 (DTI) ( 19/10/2021)
Đảo ngọc Cô Tô quyết tâm thực hiện chuyển đổi số ( 07/01/2021)
Sự kiện nội bật
Bộ Thông tin và Truyền thông thông báo kết quả đánh giá chuyển đổi số cấp bộ, cấp tỉnh năm 2020 (DTI)
Đẩy mạnh triển khai Kế hoạch cung cấp 100% DVCTT mức độ đủ điều kiện trong năm 2021
Phê duyệt Chiến lược phát triển Chính phủ điện tử hướng tới Chính phủ số giai đoạn 2021-2025, định hướng đến năm 2030
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử 6 tháng đầu năm 2020 (Công văn số 1735/BTTTT-THH ngày 12 tháng 5 năm 2020)
Nghị định về quản lý, kết nối, chia sẻ dữ liệu số của cơ quan nhà nước.
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử quý I năm 2020 (Công văn số 634/BTTTT-THH ngày 27 tháng 02 năm 2020)
Bộ Thông tin và Truyền thông: ban hành Khung Kiến trúc Chính phủ điện tử Việt Nam, phiên bản 2.0
BỘ THÔNG TIN VÀ TRUYỀN THÔNG: YÊU CẦU BÁO CÁO SỐ LIỆU VỀ PHÁT TRIỂN CHÍNH PHỦ ĐIỆN TỬ QUÝ IV/2019 (CÔNG VĂN SỐ 4045/BTTTT-THH NGÀY 13 THÁNG 11 NĂM 2019)
Bộ Thông tin và Truyền thông: Hướng dẫn các Bộ, ngành, địa phương xây dựng Kế hoạch ứng dụng CNTT trong hoạt động của CQNN năm 2020
Bộ Thông tin và Truyền thông: Ban hành Khung tham chiếu ICT phát triển đô thị thông minh
Ý kiến về Trang thông tin điện tử Cục Tin học hóa?
1. Đạt yêu cầu, 1180 phiếu (88 %)
2. Chưa đạt yêu cầu, 107 phiếu (8 %)
3. Cần thêm chủ đề, 57 phiếu (4 %)
Tổng số phiếu: 1344
THÔNG KÊ TRUY CẬP
Tổng lượt truy cập: 18945353
Người chịu trách nhiệm: Đỗ Công Anh
Chức vụ: Cục trưởng
Trụ sở chính: Tầng 21, Tòa nhà Cục Viễn thông, số 68 đường Dương Đình Nghệ, Yên Hòa, Cầu Giấy, Hà Nội.
Điện thoại: 024.37821766 Fax: 024.35378208
Ghi rõ nguồn "Trang thông tin điện tử Cục Tin học hóa" hoặc "www.aita.gov.vn" khi bạn phát hành lại thông tin từ Website này.

Ministry of Information and Communications
The subordinate units
News - Events
IT applications in state agencies
Research - evaluation
Statistics - reports
Please comment on the draft document
Multimedia data
--L


vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi en vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi nb vi vi vi

--Liên kết-- Chính phủ CIO Trung tâm chính phủ điện tử vietnamnet.vn ĐCS Việt Nam TP Hồ Chí Minh Đài tiếng nói Việt Nam Thủ đô Hà Nội Tập chí ĐCS Quốc Hội TP Đà Nẵng Thừa Thiên Huế TP Hải Phòng An Giang Bà Rịa - Vũng Tàu Bắc Ninh Bình Dương Binh Phước Bình Thuận Cà Mau Cần thơ
TÀI LIỆU - BÁO CÁO
Bộ Nội vụ: Kế hoạch chuyển đổi số đến năm 2025, định hướng đến năm 2030
Tái cấu trúc, chuyển đổi hạ tầng công nghệ thông tin thành hạ tầng số thống nhất, ổn định, linh hoạt, ưu tiên áp dụng công nghệ điện toán đám mây.
Phát triển các ứng dụng, dịch vụ theo hướng sử dụng chung hạ tầng số, nền tảng số; sử dụng các công cụ phân tích thông minh để giúp Lãnh đạo Bộ kịp thời đưa ra các quyết sách chính xác trong công tác quản lý nhà nước về lĩnh vực nội vụ đồng thời cung cấp các dịch vụ công theo phương thức số giúp người dân dễ dàng tiếp cận và sử dụng.
Tạo lập kho dữ liệu số ngành nội vụ đáp ứng các yêu cầu về kết nối, chia sẻ tài nguyên thông tin và dữ liệu.
Theo đó, mục tiêu cơ bản đến năm 2025 là:
- Đảm bảo 100% dịch vụ công trực tuyến mức độ 3, 4 phổ biến, liên quan tới nhiều người dân, doanh nghiệp, tổ chức được tích hợp lên cổng Dịch vụ công quốc gia; 100% giao dịch trên cổng Dịch vụ công trực tuyến và một cửa điện tử Bộ Nội vụ được xác thực điện tử.
- 80% dịch vụ công trực tuyến mức độ 4 được cung cấp trên nhiều phương tiện truy cập khác nhau, bao gồm cả thiết bị di động.
- 90% hồ sơ công việc được xử lý trên môi trường mạng (trừ hồ sơ công việc thuộc phạm vi bí mật nhà nước).
- 100% phần mềm quản lý văn bản và điều hành được kết nối, liên thông qua Trục liên thông văn bản quốc gia phục vụ việc gửi, nhận văn bản điện tử; 90% văn bản trao đổi với các cơ quan nhà nước (trừ văn bản mật theo quy định của pháp luật) dưới dạng điện tử.
- 100% báo cáo định kỳ (không bao gồm nội dung mật) của Bộ Nội vụ được cập nhật, chia sẻ trên Hệ thống thông tin báo cáo của Bộ và được kết nối với hệ thống thông tin báo cáo Chính phủ.
- 60% các hệ thống thông tin có liên quan đến người dân, tổ chức đã đưa vào vận hành, khai thác được kết nối, liên thông qua nền tảng tích hợp, chia sẻ dữ liệu.
- 50% hoạt động kiểm tra của Bộ Nội vụ được thực hiện thông qua môi trường số và hệ thống thông tin của cơ quan quản lý.
- Hoàn thành 100% các ứng dụng/CSDL/các dịch vụ dùng chung trong ngành Nội vụ; được kết nối liên thông phục vụ xây dựng các HTTT, CSDL trong ngành Nội vụ theo Kiến trúc CPĐT Bộ Nội vụ phiên bản 2.0.
- Hoàn thành nền tảng kết nối, tích hợp chia sẻ dữ liệu giữa các HTTT, CSDL trong ngành Nội vụ; Đảm bảo kết nối trực tiếp với các Bộ, ngành, địa phương hoặc thông qua nền tảng kết nối, tích hợp chia sẻ dữ liệu quốc gia.
- Triển khai xây dựng các CSDL quốc gia thuộc phạm vi quản lý nhà nước của Bộ; Các HTTT, CSDL chuyên ngành.
- Triển khai xây dựng kho dữ liệu tổng hợp của Bộ Nội vụ, sử dụng các công nghệ BigData, AI để quản lý, phân tích, cung cấp thông tin hỗ trợ ra quyết định cho các cấp lãnh đạo.
- Vận hành hệ thống, kết nối, chia sẻ dữ liệu và tổ chức triển khai đánh giá cải cách hành chính và đo lường sự hài lòng của người dân đối với sự phục vụ của cơ quan hành chính nhà nước qua Hệ thống ứng dụng công nghệ thông tin.
- Các giải pháp đảm bảo an toàn, an ninh thông tin cho hạ tầng kỹ thuật, các HTTT, các nội dung thông tin số trên không gian mạng của ngành Nội vụ.
- Tiếp tục hoàn thiện các cơ chế chính sách phục vụ xây dựng, vận hành, kết nối, chia sẻ, trao đổi thông tin, an toàn an ninh thông tin cho các HTTT/CSDL trong ngành Nội vụ. Hoàn thành 100% các quy định kỹ thuật về cấu trúc dữ liệu các CSDL chuyên ngành; 100% các quy định về kết nối, tích hợp, trao đổi, chia sẻ thông tin dữ liệu; 100% các HTTT được triển khai có quy định về quy chế vận hành, đảm bảo an toàn an ninh thông tin, dữ liệu.
Mục tiêu cơ bản đến năm 2030 là:
- Tiếp tục duy trì các mục tiêu đã đạt được đến năm 2025 và hướng đến đạt được các mục tiêu cụ thể như sau:
- 100% dịch vụ công trực tuyến mức độ 4 được cung cấp trên nhiều phương tiện truy cập khác nhau, bao gồm cả thiết bị di động.
- 100% hồ sơ công việc của Bộ Nội vụ được xử lý trên môi trường mạng (trừ hồ sơ công việc thuộc phạm vi bí mật nhà nước).
- Hình thành nền tảng dữ liệu và hạ tầng kết nối mạng Internet vạn vật (IoT), kết nối, chia sẻ giữa Bộ Nội vụ và các cơ quan nhà nước, giảm 30% thủ tục hành chính, tăng 30% dịch vụ sáng tạo dựa trên dữ liệu phục vụ người dân, tổ chức, doanh nghiệp.
- 70% hoạt động kiểm tra của Bộ Nội vụ được thực hiện thông qua môi trường số, báo cáo trực tuyến và hệ thống thông tin quản lý ngành Nội vụ.
- Cung cấp, chia sẻ thông tin, dữ liệu Nội vụ phục vụ cán bộ, công chức, viên chức, cơ quan nhà nước, công dân, các tổ chức và xã hội. Cung cấp dịch vụ dữ liệu, dịch vụ gia tăng trên CSDL Nội vụ hướng tới phục vụ người dân và tổ chức khai thác CSDL ngành Nội vụ có tính phí.
- Tiếp tục triển khai xây dựng các CSDL quốc gia thuộc phạm vi quản lý nhà nước của Bộ; Các HTTT, CSDL chuyên ngành.
- Tổ chức khai thác, vận hành kho dữ liệu tổng hợp của Bộ Nội vụ, sử dụng các công nghệ BigData, AI để quản lý, phân tích, cung cấp thông tin hỗ trợ ra quyết định cho các cấp lãnh đạo.
- Vận hành hệ thống, kết nối, chia sẻ dữ liệu và tổ chức triển khai đánh giá cải cách hành chính và đo lường sự hài lòng của người dân đối với sự phục vụ của cơ quan hành chính nhà nước qua Hệ thống ứng dụng công nghệ thông tin.
Bên cạnh đó, để đảm bảo thực hiện kế hoạch chuyển đổi số, Bộ Nội vụ cũng đưa ra các nhiệm vụ và giải pháp, cụ thể:
1. Đổi mới tư duy và thống nhất nhận thức về chuyển đổi số
Chủ động, đẩy mạnh công tác truyền thông, tuyên truyền, nâng cao nhận thức, trách nhiệm của Lãnh đạo, cán bộ, công chức, viên chức cho các đơn vị thuộc, trực thuộc Bộ trong việc xây dựng Chính phủ số, đổi mới phương thức làm việc theo hướng điện tử hóa, nâng cao chất lượng phục vụ người dân và doanh nghiệp qua đó tạo sự đồng thuận của người dân, doanh nghiệp về phát triển Chính phủ số.
Tổ chức các khóa đào tạo, bồi dưỡng, giới thiệu kiến thức cơ bản về chuyển đổi số cho đội ngũ cán bộ, công chức, viên chức Bộ Nội vụ.
Tổ chức các Hội nghị, Hội thảo, Tọa đàm về chuyển đổi số nhằm trao đổi kinh nghiệm, nâng cao nhận thức về chuyển đổi số.
Xây dựng các chuyên mục tuyên truyền về kế hoạch và kết quả thực hiện chuyển đổi số của Bộ trên Cổng thông tin điện tử Bộ Nội vụ.
Tăng cường sự tham gia của người dân và doanh nghiệp cùng tham gia góp ý, giám sát và sử dụng các dịch vụ, tiện ích do việc chuyển đổi số của Bộ Nội vụ mang lại.
2. Kiến tạo thể chế
a) Hoàn thiện hệ thống văn bản quy phạm pháp luật và các văn bản hướng dẫn nghiệp vụ về lưu trữ điện tử.
- Tham mưu Bộ Nội vụ trình Chính phủ, trình Quốc hội sửa đổi Luật Lưu trữ năm 2011 đáp ứng yêu cầu quản lý tài liệu lưu trữ điện tử.
- Quy định về tiêu chuẩn kho lưu trữ số và các nghiệp vụ lưu trữ tài liệu điện tử.
b) Xây dựng và thực hiện lưu trữ điện tử tại Lưu trữ cơ quan đáp ứng các yêu cầu của pháp luật và bảo đảm giải pháp tích hợp, kết nối liên thông để trích xuất, nộp lưu tài liệu có thời hạn bảo quản vĩnh viễn vào Lưu trữ lịch sử thuộc nguồn nộp lưu
c) Xây dựng và thực hiện lưu trữ điện tử tại Lưu trữ lịch sử và Lưu trữ chuyên ngành đáp ứng các yêu cầu của pháp luật và lưu trữ an toàn, tổ chức sử dụng có hiệu quả tài liệu lưu trữ điện tử.
d) Hoàn thành xây dựng các quy định về cấu trúc CSDL thành phần của Bộ, ngành Nội vụ. Các tiêu chuẩn, quy định kỹ thuật, cấu trúc dữ liệu dùng chung để trao đổi chia sẻ thông tin điện tử.
đ) Xây dựng các cơ chế, quy chế vận hành các HTTT, CSDL đảm bảo duy trì vận hành.
e) Xây dựng quy định về chia sẻ thông tin, dữ liệu ngành Nội vụ.
g) Sửa đổi, bổ sung Thông tư số 11/2012/TT-BNV ngày 17 tháng 12 năm 2012 của Bộ Nội vụ quy định về chế độ báo cáo thống kê và quản lý hồ sơ công chức.
h) Xây dựng văn bản quy định về định danh cán bộ, công chức, viên chức; sơ yếu lý lịch điện tử, lưu trữ điện tử đối với hồ sơ cán bộ, công chức, viên chức; thẻ cán bộ, công chức, viên chức điện tử.
i) Rà soát, đề xuất sửa đổi, bổ sung hệ thống văn bản quy phạm pháp luật quy định chế độ báo cáo, thống kê ngành Nội vụ trong tất cả các lĩnh vực quản lý nhà nước của Bộ Nội vụ.
3. Phát triển hạ tầng số
Đầu tư, nâng cấp hạ tầng công nghệ thông tin hoặc thuê dịch vụ hạ tầng công nghệ thông tin, trang thiết bị phục vụ Chính phủ số Bộ Nội vụ, sử dụng giải pháp công nghệ ảo hóa, điện toán đám mây, dữ liệu lớn (Big Data)…phục vụ lưu trữ các CSDL của Bộ Nội vụ.
Cung cấp các hạ tầng tri thức, tính toán, xử lý, khai thác dữ liệu… gắn với bảo đảm an toàn, an ninh thông tin, an ninh mạng phục vụ xây dựng Chính phủ số ngành Nội vụ.
Tăng cường khai thác sử dụng các CSDL quốc gia, CSDL chuyên ngành, hệ thống cung cấp dịch vụ công trực tuyến theo Kiến trúc Chính phủ điện tử Bộ Nội vụ và các quyết định của Thủ tướng Chính phủ, kết nối, liên thông với các CSDL quốc gia liên quan và các CSDL của các Bộ, ngành, địa phương.
Nghiên cứu, triển khai hạ tầng đảm bảo kết nối trong việc thu thập thông tin từ các hệ thống quản lý cán bộ trong ngành Nội vụ, tiếp cận các công nghệ mới, tham gia cuộc CMCN 4.0…
4. Phát triển dữ liệu số ngành nội vụ
Thiết kế kiến trúc dữ liệu tổng thể của Bộ Nội vụ đảm bảo nguyên tắc mỗi loại dữ liệu chỉ do một đầu mối cung cấp.
Thiết lập trung tâm dữ liệu điện tử dùng chung có thể chia sẻ, kết nối để tối ưu hóa việc khai thác và đảm bảo tính bảo mật đối với từng loại thông tin.
Tổ chức thu thập, số hóa và lập chỉ mục dữ liệu đã được số hóa, chuẩn hóa cấu trúc và chuyển đổi các dữ liệu thuộc các lĩnh vực quản lý nhà nước của Bộ thành dữ liệu điện tử.
Xây dựng Cổng công bố dữ liệu mở của Bộ Nội vụ nhằm cung cấp thông tin về chia sẻ dữ liệu Bộ Nội vụ và kết nối với Cổng dữ liệu quốc gia.
Triển khai kết nối, liên thông các cơ sở dữ liệu của Bộ Nội vụ thông qua nền tảng chia sẻ, tích hợp của Bộ (LGSP) và của quốc gia NGSP.
5. Đảm bảo an toàn, an ninh
Xây dựng Chính phủ số bảo đảm gắn kết chặt chẽ với bảo đảm an toàn thông tin, an ninh mạng, an ninh quốc gia, bảo vệ thông tin cá nhân.
Phối hợp với các đơn vị liên quan triển khai xây dựng hệ thống bảo đảm an toàn, an ninh thông tin mạng theo quy định của pháp luật; chủ trì tổ chức thuê dịch vụ đảm bảo an ninh mạng; định kỳ tổ chức tập huấn, diễn tập bảo đảm an toàn thông tin phục vụ Chính phủ số của Bộ Nội vụ. Xây dựng các chính sách và quy định về vai trò và quyền khi truy cập dữ liệu ở các mức độ khác nhau.
Xây dựng các hệ thống kỹ thuật bảo đảm an toàn thông tin phục vụ phát triển Chính phủ số gồm: hệ thống giám sát, cảnh báo sớm về nguy cơ an ninh mạng; hệ thống hỗ trợ điều phối, ứng cứu sự cố an toàn thông tin mạng.
Triển khai dịch vụ chứng thực chữ ký số cho các hệ thống thông tin để thuận tiện cho việc sử dụng của cán bộ, công chức, viên chức, các cơ quan nhà nước.
Hướng dẫn công tác bảo đảm an toàn thông tin cho các hệ thống nền tảng, hệ thống phục vụ phát triển Chính phủ số tại Bộ Nội vụ.
Đảm bảo khả năng sao lưu dự phòng, khôi phục dữ liệu quan trọng của Bộ theo các quy định hiện hành về bảo đảm an toàn, an ninh thông tin.
Triển khai các chương trình nâng cao nhận thức về an ninh, an toàn thông tin đến toàn thể cán bộ, công chức, viên chức, người lao động trong Bộ.
Nâng cao nhận thức bằng các hình thức phù hợp để phổ biến, tuyên truyền chủ trương của Nhà nước cho toàn thể công chức, viên chức, người lao động của Bộ Nội vụ về: Chính phủ điện tử, Chính phủ số.
Tăng cường kiểm tra, đôn đốc, hướng dẫn quá trình thực hiện Kế hoạch theo định kỳ hàng năm thông qua việc tổ chức các cuộc giao ban trực tiếp, trực tuyến thực hiện các nội dung của Kế hoạch.
Đầu tư, nâng cấp hạ tầng công nghệ thông tin hoặc thuê dịch vụ hạ tầng công nghệ thông tin, trang thiết bị phục vụ Chính phủ điện tử, Chính phủ số của Bộ Nội vụ.
Ưu tiên bố trí ngân sách nhà nước, bảo đảm nguồn lực xây dựng Chính phủ điện tử, Chính phủ số của Bộ. Khuyến khích thuê dịch vụ công nghệ thông tin trọn gói do các doanh nghiệp công nghệ thông tin cung cấp khi đáp ứng đủ điều kiện theo quy định hiện hành, không sử dụng nguồn vốn vay ODA có điều kiện ràng buộc để triển khai xây dựng Chính phủ điện tử, Chính phủ số. Đảm bảo kinh phí để thực hiện Kế hoạch.
Quản trị viên, Cục Tin Học Hóa
Lần xem: 402 Go top
Bộ Thông tin và Truyền thông: Phê duyệt Kế hoạch triển khai Quyết định số 505/QĐ-TTg ngày 22/4/2022 của Thủ tướng Chính phủ về Ngày Chuyển đổi số quốc gia ( 20/06/2022)
Bắc Ninh: Kết quả ứng dụng công nghệ thông tin trong hoạt động của cơ quan nhà nước, phát triển Chính quyền số và bảo đảm an toàn thông tin mạng năm 2021 ( 14/02/2022)
Bình Định: Kết quả công tác kiểm soát thủ tục hành chính, triển khai cơ chế một cửa, một cửa liên thông trong giải quyết thủ tục hành chính và thực hiện thủ tục hành chính trên môi trường điện tử năm 2021 ( 20/01/2022)
Sự kiện nổi bật
Bộ Thông tin và Truyền thông thông báo kết quả đánh giá chuyển đổi số cấp bộ, cấp tỉnh năm 2020 (DTI)
Đẩy mạnh triển khai Kế hoạch cung cấp 100% DVCTT mức độ đủ điều kiện trong năm 2021
Phê duyệt Chiến lược phát triển Chính phủ điện tử hướng tới Chính phủ số giai đoạn 2021-2025, định hướng đến năm 2030
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử 6 tháng đầu năm 2020 (Công văn số 1735/BTTTT-THH ngày 12 tháng 5 năm 2020)
Nghị định về quản lý, kết nối, chia sẻ dữ liệu số của cơ quan nhà nước.
Bộ Thông tin và Truyền thông: Yêu cầu báo cáo số liệu về phát triển Chính phủ điện tử quý I năm 2020 (Công văn số 634/BTTTT-THH ngày 27 tháng 02 năm 2020)
Bộ Thông tin và Truyền thông: ban hành Khung Kiến trúc Chính phủ điện tử Việt Nam, phiên bản 2.0
BỘ THÔNG TIN VÀ TRUYỀN THÔNG: YÊU CẦU BÁO CÁO SỐ LIỆU VỀ PHÁT TRIỂN CHÍNH PHỦ ĐIỆN TỬ QUÝ IV/2019 (CÔNG VĂN SỐ 4045/BTTTT-THH NGÀY 13 THÁNG 11 NĂM 2019)
Bộ Thông tin và Truyền thông: Hướng dẫn các Bộ, ngành, địa phương xây dựng Kế hoạch ứng dụng CNTT trong hoạt động của CQNN năm 2020
Bộ Thông tin và Truyền thông: Ban hành Khung tham chiếu ICT phát triển đô thị thông minh
Ý kiến về Trang thông tin điện tử Cục Tin học hóa?
1. Đạt yêu cầu, 1180 phiếu (88 %)
2. Chưa đạt yêu cầu, 107 phiếu (8 %)
3. Cần thêm chủ đề, 57 phiếu (4 %)
Tổng số phiếu: 1344
THÔNG KÊ TRUY CẬP
Tổng lượt truy cập: 18945316
Người chịu trách nhiệm: Đỗ Công Anh
Chức vụ: Cục trưởng
Trụ sở chính: Tầng 21, Tòa nhà Cục Viễn thông, số 68 đường Dương Đình Nghệ, Yên Hòa, Cầu Giấy, Hà Nội.
Điện thoại: 024.37821766 Fax: 024.35378208
Ghi rõ nguồn "Trang thông tin điện tử Cục Tin học hóa" hoặc "www.aita.gov.vn" khi bạn phát hành lại thông tin từ Website này.