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 en en it sv es en fr es en de es en vi vi vi vi vi vi vi vi vi vi en 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
Theo xu hướng phát triển, các thiết bị được phát triển nhỏ gọn, cơ động hơn, điển hình là sự phát triển của các thiết bị IoT. Tuy nhiên, các thiết bị IoT đòi hỏi sự giao tiếp tức thì, nhanh chóng hơn so với các phương thức thông thường và cũng đòi hỏi giao thức trong mạng thiết bị có tính bảo mật cao hơn. Điều này thách thức các giao thức mạng truyền thống và cũng là động cơ để ra đời các giao thực mạng phù hợp hơn.
Năm 1999, hai kỹ sư - Andy Stanford-Clark (IBM) và Arlen Nipper (Eurotech) khi họ phải phát minh ra một giao thức mới để kết nối các đường ống dẫn dầu trên các mạng vệ tinh không đáng tin cậy và họ đã cho ra đời MQTT. MQTT hướng tới một giao thức mạng có sự nhỏ gọn trong truyền tin, giảm thiểu tiêu hao năng lượng được sử dụng.
Một số ứng dụng nổi bật với giao thức MQTT trên thế giới có thể kể đến như Thông số kỹ thuật tiêu chuẩn SensorThings API của Open Geospatial Consortium đã được Bộ An ninh Nội địa Hoa Kỳ áp dụng, Home Assistant (nền tảng nhà thông minh mã nguồn mở) với hơn 2 triệu người dùng hiện nay trên thế giới, Eclipse Foundation với giao thức Sparkplug tương thích MQTT ứng dụng trong các thiết bị cảm biến thời gian thực phát triển thiết bị IoT vô cùng phổ biến hiện nay.
Kiến trúc giao thức MQTT
Kiến trúc mức cao nhất của MQTT gồm 2 thành phần chính là Broker và Clients.
Broker được coi là trung tâm, là điểm giao, là trục chính giao với tất cả các Clients. Nhiệm vụ chính của broker là nhận các giao tiếp từ các thiết bị xuất bản hay hiểu đơn giản là các thiết bị tạo giao tiếp, xếp các giao tiếp theo hàng đợi rồi chuyển chúng tới một địa chỉ cụ thể. Nhiệm vụ phụ của Broker là nó có thể đảm nhận thêm một vài tính năng liên quan tới quá trình truyền thông như: bảo mật giao tiếp, lưu trữ giao tiếp, ghi lại lịch sử giao tiếp, …
Client thì được chia thành 2 nhóm là xuất bản giao tiếp và theo dõi. Client hoạt động tại thiết bị di dộng nên chúng được thiết kế để có thể hoạt động một cách linh hoạt (lightweight). Client chỉ làm ít nhất một trong 2 việc là xuất bản các giao tiếp lên một kênh cụ thể hoặc theo dõi một kênh nào đó để nhận các thông điệp từ kênh này. MQTT Clients tương thích với hầu hết các nền tảng hệ điều hành hiện có: MAC OS, Windows, LInux, Androids, iOS…
+ Connect (kết nối): Thông điệp này có nhiệm vụ là thông báo việc chờ kết nối được thiết lập với máy chủ và đồng thời tạo liên kết giữa các nút trong mạng từ thiết bị đến máy chủ.Các khái niệm trong MQTT
- Cơ chế xuất bản và theo dõi: Trong một hệ thống sử dụng giao thức MQTT, nhiều node trạm (gọi là mqtt client hoặc gọi tắt là client) kết nối tới một MQTT server (gọi là Broker). Mỗi client sẽ đăng ký một vài kênh (topic), ví dụ như “/client1/channel1”, “/client1/channel2”. Quá trình đăng ký này gọi là “subscribe”, giống như chúng ta đăng ký nhận tin trên một kênh Youtube vậy. Mỗi client sẽ nhận được dữ liệu khi bất kỳ trạm nào khác gởi dữ liệu và kênh đã đăng ký. Khi một client gởi dữ liệu tới kênh đó, gọi là xuất bản.
- MQTT Broker: là một phần mềm máy tính cho phép tạo một máy chủ (server) kết nối giữa các MQTT client và các thiết bị nói chung trong mạng. MQTT Borker có thể do “host” hoặc người vận hành hệ thống tự xây dựng hoặc một bên thứ ba. Các phần mềm trên thị trường hiện nay được xây dựng ở hai dạng mã nguồn và triển khai độc quyền cho từng trường hợp cụ thể. Các Broker hoạt động như một trạm bưu điện nhận nội dung đến và chuyển nội dụng đi nhưng không sử dụng địa chỉ của client nhận như điểm đến của nội dung mà quản lý dưới dạng kênh (topic). Các client muốn có nội dung thì cần đăng ký kênh đó, sau đó khi Broker nhận được nội dung sẽ tự động chuyển đến client đã đăng ký, có thể có nhiều client cùng đăng ký một kênh và một client cũng đăng ký được nhiều kênh khác nhau trên một trạm Broker. Các client cũng có thể là điểm sản xuất nội dung và đồng thời cũng có thể đăng ký kênh của client khác cùng nội dung hoặc khác nội dung. Hiện nay Broker có thể triển khai vật lý hoặc trên đám mây, tuy nhiên triển khai trên đám mây dễ hỗ trợ khi có Broker bị hỏng hoặc bị lỗi. Broker sẽ quản lý, theo dõi mọi phiên làm việc của các nội dung, kênh và client có trao đổi nội dung trên nó.
Có thể tóm lại một số ưu điểm của Broker hay cũng là ưu điểm khi sử dụng giao thức MQTT là:
+ Quản lý, loại bỏ các kết nối client mà có dấu hiệu nguy hiểm, dễ bị tấn công hoặc không an toàn.
+ Dễ dàng quản lý quy mô tổng thể của mạng, dễ dàng mở rộng hoặc thu nhỏ tùy thuộc theo số thiết bị, số client, số kênh và số Broker.
+ Dễ dàng quản lý các trạng thái và thông tin (chứng chỉ mạng, tình trạng bảo mật, xác thực bảo mật, kết nối hay đang nghỉ) của client tham gia trong mạng.
+ Giảm thiểu tình trạng quá tải của hệ thống trong mạng, giảm thiểu nguy cơ tấn công quá tải truy cập.
- Giao tiếp (message): có định dạng mặc định là plain-text (chữ viết người đọc được), tuy nhiên người sử dụng có thể cấu hình thành các định dạng khác. Có 3 loại tin nhắn chính trong giao tiếp của MQTT:
+ Disconnect (ngắt kết nối): Thông điệp này có nhiệm vụ là thông báo việc chờ giao thức MQTT tại các client hoàn thành bất kỳ công việc nào của nó và ngắt kết nối phiên làm việc TCP/IP giữa máy chủ Broken với các nút mạng cũng như các thiết bị trong mạng.
+ Publish: Thông điệp này có nhiệm vụ là thông báo đẩy gói tin vào một luồng làm việc của ứng dụng (application thread) đồng thời chuyển yêu cầu đến MQTT client ngay sau khi khi thông báo được đưa ra.
- Kênh (topic): như một "đường truyền" logic giữa 2 điểm là xuất bản và theo dõi. Về cơ bản, khi một giao tiếp được xuất bản vào một kênh thì tất cả những theo dõi của topic đó sẽ nhận được giao tiếp này. Giao thức MQTT cho phép khai báo các topic kiểu phân cấp.
Giả sử có một hệ thống cảm biến đo thông tin môi trường trong ngôi nhà. Một ngôi nhà thường sẽ có nhiều phòng và mỗi phòng lại có bộ cảm biến môi trường riêng. Như vậy, các topic phục vụ truyền tải thông tin môi trường cho ngôi nhà có thể được khai báo như sau:
home/living-room/temperature: kênh thông tin nhiệt độ phòng khách
home/bedroom/humidity: kênh thông tin độ ẩm phòng ngủ
home/kitchen/humidity: kênh thông tin độ ẩm bếp ăn
Bên cạnh đó MQTT hỗ trợ cú pháp khai báo cho kênh như: "+" bao gồm các topic ở cùng một cấp và "#" bao gồm tất cả các topic nằm dưới topic hiện tại.
home/+/humidity: cho biết độ ẩm của tất cả các phòng trong nhà
home/bathroom/#: cho biết tất cả thông tin về phòng tắm
- Yêu cầu QoS (Qualities of service):  giao thức MQTT có 3 kiểu yêu cầu QoS
+ QoS0: Broker/client sẽ gửi giao tiếp đúng một lần, quá trình gửi được xác nhận bởi giao thức TCP/IP.
+ QoS1: Broker/client sẽ gửi giao tiếp với ít nhất một lần xác nhận từ đầu kia, nghĩa là có thể có nhiều hơn một lần xác nhận đã nhận được giao tiếp.
+ QoS2: Broker/client đảm bảm khi gửi giao tiếp thì phía nhận chỉ nhận được đúng một lần.
- Retain: là một cờ (flag) được gắn cho một giao tiếp của giao thức MQTT. Retain chỉ nhận giá trị 0 hoặc 1 (tương ứng 2 giá trị logic false hoặc true). Nếu retain = 1, broker sẽ lưu lại message cuối cùng của 1 kênh kèm theo mức QoS tương ứng. Khi client bắt đầu theo dõi kênh có giao tiếp được lưu lại đó, client ngay lập tức nhận được giao tiếp đó.
- Cầu kết nối MQTT (MQTT Bridge): là một tính năng của Broker cho phép các Broker có thể kết nối và trao đổi dữ liệu với nhau. Để sử dụng tính năng này, ta cần tối thiểu 2 Broker, trong đó, một Broker bất kỳ sẽ được cấu hình thành Bridge. Khi cấu hình MQTT bridge, ta cần lưu ý tới các thông số sau:
+ address: địa chỉ của broker cần kết nối;
+ bridge_protocol_version: phiên bản của giao thức MQTT đang sử dụng chung cho 2 broker;
+ topic: phần này định nghĩa 3 thong số: tên kênh được trao đổi giữa 2 broker, chiều trao đổi (1 chiều hay 2 chiều) và bản đồ kết nối kênh giữa 2 broker.
Mô tả dữ liệu trong một giao tiếp của MQTT
- Các bit trong một byte được gán nhãn từ 7 đến 0. Bit số 7 là bit quan trọng nhất, bit ít quan trọng nhất được gán số bit 0.
- Giá trị “Hai bit số nguyên” dữ liệu là các số nguyên không dấu 16 bit theo thứ tự big-endian: byte thứ tự cao đứng trước byte thứ tự thấp hơn. Điều này có nghĩa là một từ 16 bit được trình bày trên mạng dưới dạng Byte quan trọng nhất (MSB), tiếp theo là Byte ít quan trọng nhất (LSB).
- Giá trị “Bốn bit số nguyên” dữ liệu là các số nguyên không dấu 32 bit theo thứ tự big-endian: byte thứ tự cao đứng trước byte thứ tự thấp hơn liên tiếp. Điều này có nghĩa là một từ 32 bit được trình bày trên mạng dưới dạng Byte quan trọng nhất (MSB), tiếp theo là Byte quan trọng nhất tiếp theo (MSB), tiếp theo là Byte quan trọng nhất tiếp theo (MSB), tiếp theo là Byte ít quan trọng nhất (LSB).
- Các trường văn bản trong Gói điều khiển MQTT được mô tả sau này được mã hóa dưới dạng chuỗi UTF-8. UTF-8 [RFC3629] là một mã hóa hiệu quả các ký tự Unicode tối ưu hóa việc mã hóa các ký tự ASCII để hỗ trợ giao tiếp dựa trên văn bản. Mỗi chuỗi này được bắt đầu bằng một trường độ dài hai Byte số nguyên cung cấp số byte trong chính chuỗi được mã hóa UTF-8, Cấu trúc của Chuỗi được mã hóa UTF-8 bên dưới. Do đó, kích thước tối đa của Chuỗi được mã hóa UTF-8 là 65,535 byte. Trừ khi có quy định khác, tất cả các chuỗi được mã hóa UTF-8 có thể có bất kỳ độ dài nào trong phạm vi từ 0 đến 65,535 byte.
Hình 2: Cấu trúc của chuỗi được mã hóa UTF-8
- Kích thước Byte số nguyên được mã hóa bằng cách sử dụng một lược đồ mã hóa sử dụng một byte duy nhất cho các giá trị lên đến 127. Các giá trị lớn hơn được xử lý như bảng dưới. Bảy bit quan trọng nhất của mỗi byte mã hóa dữ liệu và bit quan trọng nhất được sử dụng để cho biết liệu có các byte theo sau trong biểu diễn hay không. Do đó, mỗi byte mã hóa 128 giá trị và một "bit tiếp tục". Số byte tối đa trong trường biến Byte số nguyên là bốn. Giá trị được mã hóa phải sử dụng số byte tối thiểu cần thiết để đại diện cho giá trị.
16,384 (0x80, 0x80, 0x01)
2,097,151 (0xFF, 0xFF, 0x7F)
2,097,151(0x80, 0x80, 0x80, 0x01)
268,435,455 (0xFF, 0xFF,  0xFF, 0x7F)
- Dữ liệu nhị phân được biểu thị bằng độ dài Số nguyên hai Byte cho biết số byte dữ liệu, theo sau là số byte đó. Do đó, độ dài của Dữ liệu nhị phân được giới hạn trong phạm vi từ 0 đến 65,535 Byte.
MQTT được thiết kế một cách nhẹ và linh hoạt nhất có thể. Chính bởi vậy nó chỉ có một lớp bảo mật ở tầng ứng dụng: bảo mật bằng xác thực (xác thực các client được quyền truy cập tới broker).
Tuy vậy, MQTT vẫn có thể được cài đặt kết hợp với các giải pháp bảo mật đa tầng khác như kết hợp với VPN ở tầng mạng hoặc SSL/TLS ở tầng transport.
MQTT được thiết kế nhằm phục vụ truyền thông machine-to-machine nhưng thực tế chứng minh nó lại linh hoạt hơn mong đợi. Nó hoàn toàn có thể áp dụng cho các kịch bản truyền thông khác như: machine-to-cloud, cloud-to-machine, app-to-app. Chỉ cần có một Broker phù hợp và MQTT client được cài đặt đúng cách, các thiết bị xây dựng trên nhiều nền tảng khác nhau có thể giao tiếp với nhau một cách dễ dàng.
Trong bài viết này, giao thức truyền thông điệp/giao tiếp MQTT được giới thiệu đến người đọc từ giới thiệu chung đến các thông tin kỹ thuật chi tiết để có thể triển khai MQTT thực tế hiện nay. MQTT là một giao thức không mới trên thế giới nhưng với sự phát triển của các thiết bị IoT thì vẫn là một giao thức mới đáng để Việt Nam học tập và ứng dụng thực tiễn trong triển khai kết nối các thiết bị trong mạng hiện nay.
Thông qua việc giới thiệu giao thức mạng này, bài đọc đưa ra các cơ sở tri thức để áp dụng phát triển hạ tầng Internet vạn vật (IoT) 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. Hi vọng trong tương lai có thể thấy các ứng dụng triển khai MQTT phục vụ người dân và cơ quan nhà nước trong khuôn khổ chính phủ điện tử của Việt Nam.
Vũ Cao Minh Đức
Tài liệu tham khảo
ISO/IEC 20922:2016, Information technology — Message Queuing Telemetry Transport (MQTT) v3.1.
MQTT Version 5.0, OASIS Standard, 07 March 2019
OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee.
Quản trị viên, Cục Tin Học Hóa
Lần xem: 961 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: 18945501
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 en vi vi vi vi vi vi vi vi vi en vi uk vi en vi hu vi vi de vi vi en vi en vi en vi ja vi en vi fr vi vi vi vi en vi af vi en vi vi vi vi vi vi vi vi ceb 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 en en en en en 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
Tiêu chuẩn lõi kết nối OpenID (Phần 2)
Ở phần 1, bài viết đã giới thiệu tổng quan và đưa ra các khái niệm cơ bản của tiêu chuẩn OpenID Connect 1.0. Để tiếp nối, phần 2 sẽ chia sẻ tiếp các cấu phần hình thành quá trình xử lý trong tiêu chuẩn OpenID Connect 1.0.
Hình 1: Một đoạn id token trong code JSON
6. Xác thực máy chủ RP
Các phương thức xác thực ứng dụng trên máy chủ RP là:
Máy chủ RP đã nhận được giá trị “client_secret” từ máy chủ ủy quyền nhằm xác thực với máy chủ ủy quyền bằng cách sử dụng sơ đồ xác thực HTTP Basic. Các bước tương tự mục 2.3.1 của Oauth 2.0 [RFC6749]
Máy chủ RP đã nhận được giá trị “client_secret” từ máy chủ ủy quyền, xác thực với máy chủ ủy quyền bằng cách đưa thông tin xác thực của máy chủ RP vào phần thân của yêu cầu
Máy chủ RP đã nhận được giá trị “client_secret” từ máy chủ ủy quyền tạo JWT dùng các thuật toán HMAC SHA, chẳng hạn như là HMAC SHA-25. HMAC (mã xác thực tin nhắn dựa trên Hash) được tính bằng cách sử dụng các octet của đại diện UTF-8 thuộc “client_secret” làm khóa chia sẻ
Máy chủ RP đã đăng ký khóa công khai ký JWT bằng chính khóa này. Máy chủ RP xác thực theo JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [OAuth.JWT] và Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [OAuth.Assertions].
JWT có thể chứa các giá trị khác về các khối thông tin như ở mã thông báo ID, bất kỳ giá trị nào không được hiểu PHẢI bỏ qua. Mã thông báo xác thực PHẢI được gửi dưới dạng giá trị của tham số “client_asserts”. Giá trị của tham số “client_assert_type” phải là “urn; ietf; params; … ”.
Máy chủ RP không tự xác thực tại mã thông báo ở điểm cuối, vì nó chỉ sử dụng luồng ẩn (và do đó không sử dụng mã thông báo ở điểm cuối) hoặc vì đó là máy chủ công cộng không có mã bí mật dùng để xác thực ứng dụng hoặc do có cơ chế xác thực khác.
Trong đó với phương thức xác thực “client_secret_jwt” và “private_key_jwt” thì JWT PHẢI chứa các giá trị yêu cầu BẮT BUỘC hoặc là CÓ THỂ chứa các yêu cầu nằm trong bảng dưới đây:
CẦN THIẾT, viết tắt cho “issuer”. Nó phải chứa “client_id” của máy chủ OAuth.
CẦN THIẾT, viết tắt cho “Audience”. Giá trị xác định cho máy chủ ủy quyền như là một đối tượng dự định. Máy chủ ủy quyền PHẢI xác định rằng đối tượng này có mã thông báo. Nó NÊN là URL của mã thông báo ở điểm cuối được tạo bởi máy chủ ủy quyền.
CẦN THIẾT, viết tắt cho “JWT ID”. Một mã định danh duy nhất cho mã thông báo, có thể được sử dụng để ngăn việc sử dụng lại mã thông báo. Các mã thông báo này PHẢI được sử dụng một lần, trừ khi các điều kiện để sử dụng lại được đàm phán giữa các bên.
CẦN THIẾT, thời gian hết hạn vào hoặc sau đó mã thông báo ID KHÔNG ĐƯỢC đồng ý cho quá trình xử lý.
KHÔNG BẮT BUỘC. Thời gian mà JWT được ban hành.
7. Đăng nhập từ bên thứ ba
Trong một số trường hợp, luồng đăng nhập được bắt đầu bởi nhà cung cấp OpenID hoặc một bên khác thay vì là từ máy chủ RP. Trong trường hợp này, bộ khởi tạo chuyển hướng đến RP tại điểm truy cập của nó ví dụ là trình duyệt của người dùng, yêu cầu RP gửi một yêu cầu xác thực sang phía máy chủ xác thực OP. Điểm cuối bắt đàu đăng nhập này có thể là một liên kết sâu trên máy chủ RP, chứ không phải là một trang đích mặc định. Máy chủ RP khi này sẽ hỗ trợ OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] đăng ký giá trị thiết bị đầu cuối bằng cách sử dụng giá trị tham số đăng ký “initiate_login_uri”.
Tại đây, bên bắt đầu yêu cầu đăng nhập sẽ bắt đầu quá trình đăng nhập bằng cách chuyển hướng đến điểm cuối bắt đăng nhập tại máy chủ RP, đồng thời truyền các tham số sau:
Giá trị này là CẦN THIẾT. Mã định danh nhà phát hành cho OP rằng máy chủ RP sẽ gửi yêu cầu xác thực tới. Giá trị của nó PHẢI là một URL sử dụng lược đồ “https”.
Giá trị này là KHÔNG BẮT BUỘC. Gợi ý cho máy chủ ủy quyền về số nhận dạng đăng nhập mà Người dùng cuối có thể sử dụng để đăng nhập. Nếu ứng dụng nhận được giá trị cho tham số có giá trị chuỗi này, thì PHẢI đưa nó vào yêu cầu xác thực làm giá trị tham số login_hint.
Giá trị này là KHÔNG BẮT BUỘC. URL mà RP được yêu cầu chuyển hướng đến sau khi xác thực. RP PHẢI xác minh giá trị của target_link_uri để tránh bị sử dụng làm công cụ chuyển hướng mở cho các trang web bên ngoài.
Các tham số có thể được truyền dưới dạng tham số truy vấn bằng phương thức HTTP GET hoặc được truyền dưới dạng giá trị biểu mẫu HTML được gửi tự động trong phần mềm mà người dùng tham gia vào quá trình xác thực khi tương tác với sever và do đó được truyền qua phương thức POST HTTP.
Các tham số khác CÓ THỂ được gửi, nếu được xác định bởi các phần mở rộng. Bất kỳ tham số nào được sử dụng không hiểu được PHẢI được máy chủ RP bỏ qua.
Máy chủ RP NÊN sử dụng tính năng chặn khung và các kỹ thuật khác để ngăn người dùng cuối đăng nhập bởi các trang web của bên thứ ba mà họ không biết thông qua các cuộc tấn công như Clickjacking (một kỹ thuật độc hại để lừa người dùng nhấn vào và bị một hành động nào đó đánh cắp thông tin người dùng từ phía OP).
8. Chữ ký và mã hóa
Tùy thuộc vào việc truyền tải thông điệp được gửi đi, tính toàn vẹn của tin nhắn có thể không được đảm bảo và người khởi tạo tin nhắn có thể không được xác thực. Để giảm thiểu những rủi ro về thiếu tính xác thực các giá trị JWT như: mã thông báo ID, phản hồi của người dùng, đối tượng yêu cầu và xác thực ứng dụng khách thì các giá trị này có thể sử dụng JSON Web Signature (JWS) để ký nội dung của chúng. Để đạt được bảo mật thông điệp, các giá trị này cũng có thể sử dụng JSON Web Encryption (JWE) để mã hóa nội dung của chúng.
Khi tin nhắn được ký và mã hóa, nó PHẢI được ký trước và sau đó được mã hóa, với kết quả là JWT lồng nhau, như được chỉ định trong JWT. Lưu ý rằng tất cả các phương thức mã hóa JWE thực hiện kiểm tra tính toàn vẹn.
Phía máy chủ OP công bố các thuật toán mã hóa và ký được hỗ trợ trong tài liệu discovery của mình hoặc có thể cung cấp thông tin này bằng các phương tiện khác. Phía máy chủ RP tuyên bố các thuật toán ký và mã hóa được yêu cầu trong “yêu cầu đăng ký động” hoặc có thể truyền đạt thông tin này bằng các phương tiện khác.
Bên ký phải chọn một thuật toán chữ ký dựa trên 2 thuật toán dưới đây được bên nhận hỗ trợ:
Hình 2 : Quá trình trao đổi mã khóa
Chữ ký bất đối xứng (Asymmetric Signatures)
Khi sử dụng Chữ ký RSA hoặc ECDSA, giá trị Tham số tiêu đề "alg" của tiêu đề JOSE PHẢI được đặt thành một thuật toán thích hợp như được xác định trong JSON Web Algorithms [JWA]. Khóa riêng được sử dụng để ký nội dung PHẢI được liên kết với khóa chung được sử dụng để xác minh chữ ký được gửi bởi người gửi trong tài liệu JWK Set của nó. Nếu có nhiều phím trong tham chiếu JWK Set tài liệu, giá trị "kid" phải được cung cấp trong JOSE Header. Việc sử dụng khóa của các khóa tương ứng PHẢI hỗ trợ ký.
Chữ ký đối xứng (Symmetric Signatures)
Khi sử dụng chữ ký dựa trên mã xác thực mẩu tin (MAC), giá trị tham số tiêu đề "alg" của JOSE Header PHẢI được đặt thành thuật toán MAC, như được xác định trong JSON Web Algorithms [JWA]. Khóa MAC được sử dụng là các octet của biểu diễn UTF-8 của giá trị "client_secret". Chữ ký đối xứng KHÔNG được sử dụng bởi các ứng dụng công cộng (không bảo mật) vì không thể giữ bí mật.
Bên mã hóa PHẢI chọn một thuật toán mã hóa dựa trên các thuật toán được phía bên nhận hỗ trợ theo 3 loại mã sau:
Mã hóa bất đối xứng: RSA
Khóa công khai mà nội dung được mã hóa PHẢI là khóa chung được sử dụng để mã hóa được người nhận xuất bản trong tài liệu JWK Set của nó. Nếu có nhiều mã khóa trong tham chiếu JWK Set. Việc sử dụng khóa của các khóa tương ứng PHẢI có sự mã hóa.
Mã hóa bất đối xứng: đường ong Elliptic
Tạo khóa công khai Elliptic Curve phù hợp cho phần tử “epk” của Tiêu đề JOSE. Khóa công khai khác được sử dụng cho tính toán thỏa thuận khóa PHẢI là khóa chung được công bố bởi người nhận trong tài liệu JWK Set của nó. Sử dụng thuật toán ECDH-ES để thống nhất Khóa mã hóa nội dung được sử dụng để mã hóa JWT đã ký. Việc sử dụng khóa của các khóa tương ứng PHẢI hỗ trợ mã hóa.
Mã hóa đối xứng
Khóa mã hóa đối xứng được lấy từ giá trị “client_secret” bằng cách sử dụng hàm băm SHA-2 bị cắt ngắn của các octet của biểu diễn UTF-8 của “client_secret”. Đối với các khóa từ 256 bit trở xuống, SHA-256 được sử dụng; đối với các khóa gồm 256-384 bit, SHA-384 được sử dụng; đối với các khóa 385-512 bit, SHA-512 được sử dụng. Giá trị băm PHẢI được cắt ngắn đến độ dài bit thích hợp cho gói khóa AES hoặc thuật toán mã hóa trực tiếp được sử dụng, ví dụ, cắt băm SHA-256 thành 128 bit cho A128KW. Nếu cần một khóa đối xứng có lớn hơn 512 bit, thì một phương pháp khác để lấy khóa từ “client_secret” sẽ phải được xác định bởi một phần mở rộng. Mã hóa đối xứng KHÔNG được sử dụng bởi các Khách hàng công cộng (không bảo mật) vì không thể giữ bí mật.
9. Truy cập ngoại tuyến
OpenID CC 1.0 xác định giá trị “scope” để yêu cầu ngoại tuyến theo giá trị sau:
Đây là giá trị KHÔNG BẮT BUỘC. Giá trị “scope” này yêu cầu rằng một mã thông báo làm mới OAuth 2.0 được máy chủ nào đó phát hành có thể dùng để có được mã truy cập mới và truy cập vào điểm truy cập cuối với thông tin người dùng ngay cả khi người dùng này không có mặt (không truy cập).
Khi mà truy cập ngoại tuyến được yêu cầu, một giá trị tham số “prompt” của “consent” PHẢI được sử dụng. Trường hợp người dùng có đủ các điều kiện để máy chủ ủy quyền xử lý yêu cầu cho phép truy cập ngoại tuyến vào các tài nguyên thì máy chủ ủy quyền PHẢI luôn nhận được sự đồng ý để trả lại một mã thông báo truy cập mới nhằm cho phép truy cập ngoại tuyến vào tài nguyên đã được yêu cầu. Sự đồng ý của người dùng đã lưu trước đây không phải lúc nào cũng đủ để cấp quyền truy cập ngoại tuyến.
Khi nhận được một giá trị “offine_access”, máy chủ ủy quyền:
- PHẢI đảm bảo rằng tham số có chứa giá trị “consent” trừ khi có các điều kiện khác để xử lý yêu cầu cho phép truy cập ngoại tuyến như nói ở trên. Nếu có đủ điều kiện được đáp ứng với yêu cầu của máy chủ ủy quyền thì máy chủ sẽ bỏ qua yêu cầu “offine_access”
- PHẢI bỏ qua giá trị “offine_access” trừ khi máy chủ RP sử dụng một giá trị “respone_type” mà sẽ có kết quả trong mã ủy quyền được trả lại.
- PHẢI phản hồi một cách rõ ràng hoặc có sự đồng ý từ tất cả máy chủ uy tín khi đăng ký với giá trị “application_type” là “web”.
- NÊN phải hồi một cách rõ ràng hoặc có sự đồng ý từ tất cả máy chủ uy tín khi đăng ký với giá trị “application_type” là “native”.
Việc sử dụng mã thông báo làm mới không dành riêng cho trường hợp sử dụng “offine_access”. Máy chủ ủy quyền có thể cấp mã thông báo làm mới trong một các trường hợp khác mà nằm ngoài phạm vi của điều kiện kỹ thuật này.
10. Sử dụng mã thông báo làm mới
Để mã thông báo ở Endpoint được yêu cầu có thể sử dụng một mã thông báo làm mới là sử dụng giá trị “grant_type” là “fresh_token”. Để làm mới mã thông báo truy cập, máy chủ RP PHẢI xác thực với mã thông báo ở Endpoint bằng phương thức xác thực được đăng ký cho “client_id” của nó. Máy chủ RP gửi các tham số qua HTTP POST đến mã thông báo ở Endpoint bằng cách sử dụng tuần tự hóa biểu mẫu.
Máy chủ ủy quyền PHẢI xác thực mã thông báo làm mới. Tiếp đó nó PHẢI xác minh rằng nó đã được cấp quyền cho máy chủ RP và phải chắc chắn rằng máy chủ RP đã xác thực thành công với phương thức xác thực ứng dụng của phía máy chủ RP cấp.
Sau khi xác thực thành công mã thông báo làm mới, phần nội dung phản hồi chính là mã phản hồi thông báo (Token Response) ngoài trừ việc nó có thể không chứa “id_token”.
Nếu mã thông báo ID được trả về do yêu cầu làm mới từ mã thông báo, các yêu cầu được áp dụng như sau:
- Giá trị “iss” PHẢI giống như trong mã thông báo ID được cấp khi xác thực ban đầu xảy ra.
- Giá trị “sub” PHẢI giống như trong mã thông báo ID được cấp khi xác thực ban đầu xảy ra.
- Giá trị “iat” PHẢI thể hiện thời gian mã thông báo ID mưới được phát hành.
- Giá trị “aud” PHẢI giống như trong mã thông báo ID được cấp khi xác thực ban đầu xảy ra.
- Nếu Mã thông báo ID chứa xác nhận “auth_time”, giá trị của nó PHẢI biểu thị thời gian xác thực ban đầu - không phải là thời gian mã thông báo ID mới được phát hành.
- Giá trị “azp” PHẢI giống như trong mã thông báo ID được cấp khi xác thực ban đầu xảy ra, nếu không có giá trị “azp” nào xuất hiện trong mã thông báo ID gốc, thì IKHÔNG PHẢI xuất hiện trong mã thông báo ID mới và nếu không, các quy tắc tương tự sẽ được áp dụng khi áp dụng Mã thông báo ID tại thời điểm xác thực ban đầu.
Trong trường hợp yêu cầu làm mới không hợp lệ hoặc trái phép, máy chủ ủy quyền sẽ trả về phản hồi mã lỗi phản hồi (Token Error Response).
11. Tuần tự hóa và hoạt động theo chuỗi
Các nội dung trao đổi được tuần tự hóa bằng một trong các phương pháp sau:
- Chuỗi tuần tự truy vấn
- Biểu mẫu nối tiếp
- Tuần tự hóa JSON
Khi xử lý một số nội dung trao đổi, OpenID CC 1.0 yêu cầu so sánh các giá trị trong nội dung này với những giá trị đã biết. Ví du là so sánh các chuỗi Unicode, nó có ý nghĩa bảo mật quan trọng.
Do đó việc so sánh giữa các chuỗi JSON và các chuỗi Unicode khác PHẢI được thực hiện như theo chỉ định dưới đây:
- Xóa mọi JSON được áp dụng thoát để tạo ra một loạt các điểm mã Unicode.
- Chuẩn hóa Unicode [USA 15] KHÔNG được áp dụng tại bất kỳ điểm nào đối với chuỗi JSON hoặc chuỗi được so sánh vs chuỗi đó.
- So sánh giữa hai chuỗi PHẢI được thực hiện dưới dạng điểm mã Unicode để so sánh một cách bình đẳng.
Ở một số nơi, thì theo tiêu chuẩn này sử dụng danh sách các chuỗi được phân tách bằng dấu cách. Trong tất cả các trường hợp như vậy, một số ký tư ASCII (0x20) PHẢI được sử dụng làm dấu phân cách.
Thế kỉ 21 - kỉ nguyên của khoa học và công nghệ, sự phát triển mạnh như vũ bão của công nghệ số đã đem lại một cuộc sống vô cùng tiện ích cho con người. Trong kỉ nguyên ấy, Việt Nam - 1 trong những đất nước có tốc độ phát triển nhanh nhất thế giới là mảnh đất vô cùng màu mỡ của nền công nghệ số. Đặc biệt, với tính mở của nền công nghệ số, việc bảo mật dữ liệu và thông tin là vô cùng cần thiết.
Chính vì vậy, tiêu chuẩn OpenID Connect 1.0 sẽ góp phần quan trọng để Việt Nam có thể phát triển và mở rộng hệ thống chính phủ điện tử và dịch vụ công. Trên hết, yếu tố bảo mật và toàn vẹn dữ liệu đang là một vấn đề nóng được cả thế giới quan tâm, điều cần thiết hơn cả là việc ứng dụng tiêu chuẩn giúp cho việc bảo vệ giữ liệu của chính phủ điện tử sau này, đồng thời là lý thuyết căn bản cho việc chia sẻ dữ liệu với các bên ở hiện tại và trong tương lai.
Vũ Cao Minh Đức
Tài liệu tham khảo:
Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT).
Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012 (TXT).
Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” draft-ietf-jose-json-web-signature (work in progress), July 2014 (HTML).
Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” draft-ietf-oauth-json-web-token (work in progress), July 2014 (HTML).
Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.
Hardt, D., cụm Khung ủy quyền OAuth 2.0 , RFC 6749, tháng 10 năm 2012 ( TXT ).
Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.
Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).
Quản trị viên, Cục Tin Học Hóa
Lần xem: 1051 Go top
Xây dựng chiến lược chuyển đổi số, một số nội dung cơ bản ( 29/09/2022)
Khai phá dữ liệu – Tổng quan, ứng dụng và các nền tảng thông dụng để khai phá dữ liệu ( 29/09/2022)
PHÂN TÍCH CÁC HIỆN TRẠNG TRONG TRIỂN KHAI CHÍNH PHỦ ĐIỆN TỬ VÀ BÀI HỌC KINH NGHIỆM CHO CÁC QUỐC GIA ĐANG PHÁT TRIỂN (PHẦN 1) ( 01/08/2022)
ĐO LƯỜNG MỨC ĐỘ SẴN SÀNG CỦA CHÍNH PHỦ ĐIỆN TỬ Ở SRILANKA: QUAN ĐIỂM KHẢO SÁT (PHẦN 2) ( 01/08/2022)
ĐO LƯỜNG MỨC ĐỘ SẴN SÀNG CỦA CHÍNH PHỦ ĐIỆN TỬ Ở SRILANKA: QUAN ĐIỂM KHẢO SÁT (PHẦN 1) ( 29/07/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: 18945405
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 E-government center vietnamnet.vn Communist Party of Vietnam 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 vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi 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

Cao Bằng: Đánh giá, xếp hạng mức độ ứng dụng công nghệ thông tin, phát triển Chính quyền điện tử của cơ quan nhà nước năm 2021 - Cục Tin học hóa
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 > Ứng dụng CNTT trong Cơ quan nhà nước
Cao Bằng: Đánh giá, xếp hạng mức độ ứng dụng công nghệ thông tin, phát triển Chính quyền điện tử của cơ quan nhà nước năm 2021
Ngày 30 tháng 12 năm 2021, Ủy ban nhân dân tỉnh Cao Bằng ban hành báo cáo số 3714/BC-UBND về đánh giá, xếp hạng mức độ ứng dụng công nghệ thông tin, phát triển Chính quyền điện tử của cơ quan nhà nước tỉnh Cao Bằng năm 2021 với kết quả như sau:
Ngày đăng : 15/01/2022    Xem với cỡ chữ
1. Về đánh giá, xếp hạng mức độ ứng dụng CNTT của cơ quan chuyên môn thuộc UBND tỉnh
Thực hiện bằng phương pháp chấm điểm đối với 6 nhóm tiêu chí, gồm: Hạ tầng kỹ thuật CNTT; Ứng dụng CNTT trong hoạt động; Cung cấp thông tin trên trang thông tin điện tử; Cung cấp Dịch vụ công trực tuyến; Cơ chế, chính sách, quy định, báo cáo ứng dụng CNTT; Nhân lực cho ứng dụng CNTT.
Trên cơ sở tổng điểm đánh giá, tiến hành xếp hạng mức độ ứng dụng CNTT theo 4 mức độ từ cao đến thấp: Mức I (cao nhất – điểm tối thiểu đạt 54), Mức II (điểm tối thiểu đạt 48), Mức III (điểm tối thiểu đạt 42) và Mức IV (điểm tối thiểu đạt 36). Các đơn vị không đạt điểm tối thiểu ở mức thấp nhất (Mức IV) thì không được xếp hạng.
Kết quả đánh giá, xếp hạng mức độ UDCNTT của các cơ quan chuyên môn thuộc Ủy ban nhân dân tỉnh:
Trong năm 2021, kết quả đánh giá mức độ ứng dụng CNTT của các cơ quan chuyên môn thuộc UBND tỉnh có sự thay đổi so với năm 2020. Trong đó, tiêu chí Ứng dụng CNTT và cung cấp thông tin trên trang thông tin điện tử, cung cấp dịch vụ công trực tuyến được quan tâm nhiều nhất. Qua đó thấy rằng năm 2021, các cơ quan, đơn vị đã quan tâm đến việc triển khai các ứng dụng, cung cấp dịch vụ công trực tuyến phục vụ phát triển Chính quyền điện tử, công khai, minh bạch thông tin hoạt động của cơ quan nhà nước nhằm phục vụ người dân, doanh nghiệp ngày càng tốt hơn.
Về mức độ xếp hạng, không có cơ quan đạt Mức I, có 05 cơ quan đạt Mức II, 07 cơ quan đạt Mức III, 07 cơ quan đạt Mức IV, 01 cơ quan không được xếp hạng do điểm số không đạt theo yêu cầu.
Trong đó: Sở Giáo dục và đào tạo đạt 53,2 điểm (Mức II) là đơn vị xếp thứ nhất 04 năm liên tiếp (2018, 2019, 2020, 2021) về mức độ ứng dụng CNTT của các cơ quan chuyên môn thuộc UBND tỉnh, với các tiêu chí đều có điểm số cao hơn mặt bằng chung các đơn vị khác. Sở Lao động – Thương binh và Xã hội trong năm 2021 cũng có sự thay đổi từ vị trí thứ 6 năm 2020 lên vị trí thứ 2 năm 2021 (51,6 điểm); Sở Y tế là đơn vị đang đứng ở vị trí thứ hai năm 2020 bị tụt bậc về vị trí thứ 12 năm 2021; Sở Xây dựng là đơn vị cuối bảng xếp hạng 02 năm liền (2019, 2020) cũng đã có bước nhẩy vọt lên vị trí thứ 9 trong năm 2021; Thanh tra tỉnh đạt 32,2 điểm là đơn vị đứng cuối bảng xếp hạng năm 2021.
Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 21 điểm.
Kết quả đánh giá theo từng nhóm tiêu chí gồm:
- Tiêu chí Hạ tầng kỹ thuật CNTT
Tiêu chí Hạ tầng kỹ thuật CNTT của từng cơ quan, đơn vị giảm nhẹ so với năm 2020 vì các cơ quan, đơn vị chưa thực sự quan tâm đầu tư cho an toàn hệ thống mạng và lưu trữ dữ liệu. Nhóm các Sở có tổng điểm đánh giá cao nhất ở tiêu chí Hạ tầng kỹ thuật CNTT gồm: Giáo dục và Đào tạo, Y tế, Lao động – Thương binh và Xã hội đều đạt 8,0 điểm (100% điểm tối đa). Ban Dân tộc là đơn vị đứng cuối bảng xếp hạng trong 2 năm 2020, 2021 đạt 2,0 điểm (25% điểm tối đa).
Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 6,0 điểm.
- Tiêu chí Ứng dụng CNTT trong hoạt động cơ quan nhà nước:
Các Sở có tổng điểm đánh giá cao nhất ở tiêu chí Ứng dụng CNTT trong hoạt động cơ quan nhà nước là: Sở Giáo dục và Đào tạo và Sở Xây dựng đạt 16,0 điểm (đạt 100% điểm tối đa); đơn vị có tổng điểm đánh giá thấp là Sở Ngoại vụ đạt 12,0 điểm (đạt 75% điểm tối đa). Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 4 điểm.
- Tiêu chí Trang thông tin điện tử của cơ quan nhà nước:
Nhóm các Sở có tổng điểm đánh giá cao nhất ở tiêu chí Cung cấp thông tin trên trang thông tin của cơ quan nhà nước là: Giáo dục và Đào tạo; Văn hóa, Thể thao và Du lịch; Tài chính đạt 19,0 điểm (đạt 95% điểm tối đa); các đơn vị có tổng điểm đánh giá thấp nhất ở tiêu chí Cung cấp thông tin trên Trang thông tin của cơ quan nhà nước là: Sở Giao thông Vận tải (GTVT), Thanh tra tỉnh, Ban Quản lý Khu kinh tế tỉnh đạt 9,0 điểm (đạt 45% điểm tối đa). Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 10 điểm.
- Tiêu chí Cung cấp dịch vụ công trực tuyến
Nhóm các Sở có tổng điểm đánh giá cao nhất ở tiêu chí Cung cấp dịch vụ công trực tuyến mức độ 3, mức độ 4 là: Tư pháp, Tài nguyên và Môi trường, Văn hóa, Thể thao và Du lịch đều đạt 4,0 điểm (đạt 67% điểm tối đa); đơn vị có điểm đánh giá thấp nhất trong 2 năm 2020, 2021 ở tiêu chí cung cấp dịch vụ công trực tuyến là Thanh tra tỉnh với 0,2 điểm điểm (đạt 3,0% điểm tối đa). Chênh lệch giữa đơn vị có điểm số cao nhất và có điểm số cao nhất và đơn vị có điểm số thấp nhất là 3,8 điểm.
- Tiêu chí Nhân lực cho ứng dụng CNTT:
Nhóm các Sở có điểm số đánh giá cao nhất ở Tiêu chí Nguồn nhân lực cho ứng dụng CNTT là: Giáo dục và Đào tạo, Thông tin và Truyền thông, Văn phòng UBND tỉnh, Ngoại vụ, Giao thông Vận tải, Xây dựng, Lao động – Thương binh và Xã hội đều đạt 5,0 điểm (đạt 100% điểm tối đa); có 03 đơn vị đạt điểm thấp nhất là Thanh tra tỉnh, Ban Dân tộc, Ban Quản lý Khu kinh tế tỉnh với 2,0 điểm (đạt 40% điểm tối đa). Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 3,0 điểm.
- Tiêu chí Cơ chế, chính sách và các quy định cho ứng dụng CNTT:
Nhìn chung, chính sách và các quy định cho ứng dụng CNTT của các cơ quan chuyên môn thuộc UBND tỉnh đã được nhiều đơn vị quan tâm tích cực. các Sở, ngành: Giáo dục và Đào tạo, Nội vụ, Văn phòng UBND tỉnh, Tài chính, Tư pháp, Xây dựng, Ban Quản lý Khu kinh tế, Ban Dân tộc, lao động – Thương binh và Xã hội, Tài nguyên và Môi trường, Giao thông Vận tải đạt điểm tối đa ở  tiêu chí này với 5,0 điểm (đạt 100% điểm tối đa); đơn vị có tổng điểm đánh giá thấp nhất là Sở Y tế đạt 2,0 điểm (đạt 40% điểm tối đa) (theo số liệu do Sở Y tế cung cấp).
Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 3,0 điểm.
2. Về đánh giá, xếp hạng mức độ chính quyền điện tử cấp huyện:
Thực hiện bằng phương pháp chấm điểm với 2 nhóm tiêu chí chính:
- Đánh giá điều kiện sẵn sàng Chính quyền điện tử, gồm 03 nhóm tiêu chí: Đánh giá cơ sở hạ tầng thông tin; đánh giá nhân lực CNTT; đánh giá môi trường chính sách về ứng dụng CNTT.
- Đánh giá kết quả Chính quyền điện tử gồm 04 nhóm tiêu chí: đánh giá mức độ hiện diện; đánh giá mức độ tương tác; đánh giá mức độ giao dịch; đánh giá mức độ chuyển đổi.
Xếp hạng mức độ phát triển chính quyền điện tử cấp huyện được thực hiện căn cứ vào tổng điểm số đánh giá của từng huyện và xếp hạng theo 4 mức độ: Mức I (cao nhất – điểm tối thiểu đạt 108), Mức II (điểm tối thiểu đạt 100,4), Mức III (điểm tối thiểu đạt 93,05) và Mức IV (điểm tối thiểu đạt 85,7). Đơn vị không đạt điểm tối thiểu ở mức thấp nhất (Mức IV) và không cung cấp số liệu phục vụ việc đánh giá thì không được xếp hạng.
Kết quả đánh giá, xếp hạng mức độ phát triển chính quyền điện tử của UBND các huyện, thành phố:
Kết quả xếp hạng tổng thể mức độ phát triển chính quyền điện tử của UBND các huyện, thành phố tăng so với năm 2020. Có 01 đơn vị đạt điểm đánh giá xếp hạng Mức II và 9 đơn vị không đạt điểm đánh giá xếp hạng mức IV (mức thấp nhất). Trong đó, UBND thành phố Cao Bằng là đơn vị xếp thứ nhất với 105,86 điểm (đạt 88% điểm tối đa); UBND huyện Thạch An là đơn vị xếp cuối bảng xếp hạng với 58,55 điểm (đạt 48,8% điểm tối đa).
Các huyện, thành phố đã có sự thay đổi về vị trí xếp hạng do đã triển khai tốt các hạng mục ứng dụng CNTT và đạt được kết quả tốt, đặc biệt là đẩy mạnh triển khai cung cấp dịch vụ công trực tuyến mức độ 3, 4, cung cấp công khai, minh bạch thông tin về hoạt động của cơ quan nhà nước cấp huyện, thành phố trên trang thông tin điện tử. Tiêu chí Ứng dụng CNTT, kết quả xây dựng Chính quyền điện tử của các huyện, thành phố trong năm 2021 tăng nhiều so với năm 2020. Các huyện, thành phố đã quan tâm triển khai nhiều ứng dụng phục vụ xây dựng và phát triển Chính quyền điện tử. Tuy nhiên, mức độ tăng điểm chưa đồng đều; chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất cao (47,31 điểm).
Kết quả đánh giá theo từng nhóm tiêu chí gồm:
- Nhóm tiêu chí đánh giá điều kiện sẵn sàng ứng dụng CNTT, xây dựng chính quyền điện tử
Đơn vị có tổng điểm cao nhất tại nhóm tiêu chí Đánh giá điều kiện sẵn sàng là UBND thành phố với 37,11 điểm (đạt 93% điểm tối đa); đơn vị có tổng điểm đánh giá điều kiện sẵn sàng thấp nhất là UBND huyện Thạch An với 14,29 điểm (đạt 36% điểm tối đa). Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 22,82 điểm.
+ Nhóm tiêu chí Cơ sở hạ tầng thông tin:
Đơn vị có tổng điểm đánh giá cao nhất tại tiêu chí Cơ sở hạ tầng thông tin là UBND thành phố: 21,29 điểm (đạt 88,7% điểm tối đa); đơn vị có tổng điểm đánh giá cơ sở hạ tầng thông tin thấp nhất là UBND huyện Thạch An: 8,64 điểm (đạt 36% điểm tối đa).
Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 12,65 điểm.
+ Nhóm tiêu chí Nhân lực CNTT:
Đơn vị có tổng điểm đánh giá cao nhất tại tiêu chí nhân lực CNTT là UBND thành phố: 8,82 điểm (đạt 98% điểm tối đa); đơn vị có tổng điểm đánh giá nhân lực CNTT thấp nhất là UBND huyện Thạch An, Bảo Lâm: 3,64 điểm (đạt 40% điểm tối đa). Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 3,83 điểm.
+ Nhóm tiêu chí Cơ chế, chính sách, quy định, báo cáo CNTT đó là UBND huyện Hạ Lang, UBND thành phố Cao Bằng, UBND huyện Nguyên Bình: 7,0 điểm (đạt 100% điểm tối đa); đơn vị có tổng điểm đánh giá cơ chế, chính sách, quy định, báo cáo CNTT thấp nhất là UBND huyện Bảo Lâm, Thạch An: 2,0 điểm (đạt 28,6 % điểm tối đa). Chênh lệch giữa đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 5,0 điểm.
- Nhóm tiêu chí đánh giá kết quả Chính quyền điện tử
Đơn vị có tổng điểm đánh giá mức độ ứng dụng cao nhất là UBND thành phố: 69,74 điểm (đạt 87% điểm tối đa); đơn vị có tổng điểm đánh giá mức độ ứng dụng thấp nhất là UBND huyện Bảo Lạc: 41,16 điểm (đạt 51% điểm tối đa). Chênh lệch giữa các đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 23,58 điểm.
+ Nhóm tiêu chí Mức độ hiện diện
Đơn vị có tổng điểm đánh giá cao nhất tại tiêu chí mức độ hiện diện là UBND thành phố: 36,0 điểm (đạt 95% điểm tối đa); đơn vị có tổng điểm đánh giá mức độ hiện diện thấp nhất là UBND huyện Trùng Khánh, Quảng Hòa: 20,0 điểm (đạt 53% điểm tối đa). Chênh lệch giữa các đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 16,0 điểm.
+ Nhóm tiêu chí Mức độ tương tác
Đơn vị có tổng điểm đánh giá cao nhất tại tiêu chí mức độ tương tác là UBND huyện Bảo Lâm: 29,95 điểm (đạt 99,8% điểm tối đa); đơn vị có tổng điểm đánh giá mức độ tương tác thấp nhất là UBND huyện Hạ Lang: 17,90 điểm (đạt 60% điểm tối đa). Chênh lệch giữa các đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 12,05 điểm.
+ Nhóm tiêu chí Mức độ giao dịch
Đơn vị có tổng điểm đánh giá cao nhất tại tiêu chí mức độ giao dịch là UBND huyện Hòa An, UBND thành phố: 3,26 điểm (đạt 36% điểm tối đa); đơn vị có tổng điểm đánh giá mức độ giao dịch thấp nhất là UBND huyện Thạch An: 0,26 điểm (đạt 2,9% điểm tối đa). Chênh lệch giữa các đơn vị có điểm số cao nhất và đơn vị có điểm số thấp nhất là 3,0 điểm.
+ Nhóm tiêu chí Mức độ chuyển đổi
Tiêu chí Mức độ chuyển đổi là mức độ phát triển cao nhất của Chính quyền điện tử, năm 2021 điểm số tại tiêu chí này vẫn không thay đổi. Cụ thể: Có 10 huyện, thành phố có cùng tổng điểm đánh giá về mức độ chuyển đổi (tại tiêu chí thành phần là có ứng dụng biểu mẫu điện tử dùng chung cấp huyện): 1,0 điểm (đạt 33,3% điểm tối đa).
Như vậy, trong năm 2021 nhiều đơn vị đã tích cực cải thiện các chỉ số, quan tâm đồng bộ các giải pháp ứng dụng công nghệ thông tin, phát triển Chính quyền điện tử. Tuy nhiên, mức độ cải thiện các chỉ số giữa các cơ quan, đơn vị chưa được đồng đều, một số đơn vị tụt hạng sâu so với năm 2020. Hầu hết các đơn vị cấp huyện (trừ UBND thành phố Cao Bằng) mặc dù điểm số có cải thiện so với năm trước nhưng còn ở mức thấp so với điểm tối đa, cho thấy các chỉ tiêu ứng dụng công nghệ thông tin, chính quyền điện tử còn rất hạn chế so với yêu cầu đặt ra.
Qua kết quả đánh giá mức độ ứng dụng CNTT, phát triển Chính quyền điện tử năm 2021, Chủ tịch UBND tỉnh yêu cầu người đứng đầu của các Sở, ban, ngành, UBND các huyện, thành phố phát huy trách nhiệm, quyết tâm, chỉ đạo triển khai có hiệu quả nhiệm vụ xây dựng Chính quyền điện tử, hướng tới Chính quyền số tại cơ quan, đơn vị bằng các giải pháp thiết thực, hiệu quả; chú trọng cung cấp dịch vụ công trực tuyến; công khai, minh bạch thông tin trên trang thông tin điện tử; quan tâm thích đáng công tác xây dựng, tập hợp dữ liệu số trong từng ngành, lĩnh vực và địa phương; gắn kết hiệu quả ứng dụng công nghệ thông tin và cải cách hành chính; chủ động xác định các bài toán  chuyển đổi số đưa vào triển khai trong ngành, lĩnh vực, đơn vị; đẩy mạnh công tác tuyên chuyền, phổ biến, nâng cao nhận thức về Chính phủ điện tử, chuyển đổi số; có giải pháp khắc phục những tồn tại, hạn trế nhằm nâng cao hiệu quả ứng dụng CNTT, xây dựng Chính quyền điện tử hướng tới Chính quyền số.
Quản trị viên, Cục Tin Học Hóa
Lần xem: 148 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: 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.

Cao Bang: Evaluating and ranking the level of information technology application and e-Government development of state agencies in 2021 - Department of Computerization
Ministry of Information and Communications
The subordinate units
Believe


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 en vi vi vi vi vi en fi vi fr en vi en en vi en en vi en en vi en en vi fi hbs_lat vi en en en vi vi vi vi vi vi en fi vi en fi vi en fi vi en en vi pt en vi en fi vi vi vi vi vi vi vi fa fi vi en fi vi en fi vi vi vi vi vi vi vi fa fi vi en fi vi vi vi vi vi vi vi en fi vi en fi vi en en vi vi vi vi vi vi fr tr vi kn fi vi en fi vi vi vi vi vi vi de en vi en en vi kn en vi en en vi en en vi en en vi de en vi en en vi en en vi vi vi vi vi vi vi ceb en vi vi vi vi vi vi is fi vi en fi vi en fi vi en en vi en en vi en en vi en en vi kn en vi en en vi en en vi en en vi en en vi kn en vi vi vi vi vi vi az fi vi en fi vi en fi vi en en vi en fi vi kn en vi en en vi en en vi en en vi en en vi en en vi en en vi vi vi vi vi vi vi vi vi is fi 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 vi vi vi vi vi vi vi vi vi 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

Tiêu chuẩn OpenAPI phiên bản 3.0.3 (OpenAPI Specification version 3.0.3) - Phần II - Cục Tin học hóa
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
Tiêu chuẩn OpenAPI phiên bản 3.0.3 (OpenAPI Specification version 3.0.3) - Phần II
Tiếp nối phần 1 với các khái niệm cơ bản cùng tổng quan đơn giản nhất về tiêu chuẩn OAS, phần 2 sẽ đi sâu hơn vào yếu tố đối tượng của tiêu chuẩn, đây là yếu tố chính giúp xây dựng các API mở cho người dùng. Phần 2 của bài viết sẽ phù hợp hơn nếu muốn tìm hiểu sâu và nắm bắt toàn bộ về tiêu chuẩn này.
Hình 1: mã nguồn xây dựng cho một API được xây dựng trên chuẩn OpenAPI
6. Đối tượng của OpenAPI
Là trường dữ liệu bắt buộc. Chuỗi này phải tuân thủ phiên bản ngữ nghĩa (Semantic ver) mà tiêu chuẩn OAS sử dụng. Giá trị “openapi” phải được sử dụng bằng các công cụ và máy chủ được nêu trong tài liệu để diễn giải. Giá trị này không không liên quan đến chuỗi API “info.version”
Là trường dữ liệu bắt buộc. Giúp cung cấp siêu dữ liệu về API. Siêu dữ liệu có thể được sử dụng bằng công cụ theo yêu cầu.
Là trường dữ liệu bắt buộc. Cung cấp thông tin về các đường dẫn và hoạt động có sẵn cho API.
Một phần tử để chứa các lược đồ khác nhau cho đặc tả.
Tuyên bố về các cơ chế bảo mật có thể được sử dụng trên API. Danh sách các giá trị bao gồm các đối tượng yêu cầu bảo mật thay thế có thể được sử dụng. Chỉ một trong các đối tượng yêu cầu bảo mật cần được đáp ứng để cho phép một yêu cầu. Các hoạt động riêng lẻ có thể ghi đè định nghĩa này. Để làm cho bảo mật là tùy chọn, một yêu cầu bảo mật trống ( {}) có thể được bao gồm trong mảng.
Danh sách các thẻ được đặc tả sử dụng với siêu dữ liệu bổ sung. Thứ tự của các thẻ có thể được sử dụng để phản ánh thứ tự của chúng bằng các công cụ phân tích cú pháp. Không phải tất cả các thẻ được sử dụng đều phải được khai báo. Các thẻ không được khai báo có thể được sắp xếp ngẫu nhiên hoặc dựa trên logic của công cụ. Mỗi tên thẻ trong danh sách phải là duy nhất.
Tài liệu bên ngoài bổ sung.
7. Đối tượng Info
Đối tượng cung cấp siêu dữ liệu về API. Siêu dữ liệu có thể được máy chủ sử dụng nếu cần, và có thể được trình bày trong các công cụ chỉnh sửa hoặc tạo tài liệu để thuận tiện.
Là trường dữ liệu bắt buộc. Đây là nội dung của API
Đây là miêu tả ngắn gọn về API. Cú pháp CommonMark có thể được sử dụng để biểu diễn văn bản đa dạng thức.
URL của Điều khoản dịch vụ cho API và phải ở định dạng URL.
Thông tin liên hệ cho API được tiếp xúc.
Thông tin giấy phép cho API được tiết lộ.
Là trường dữ liệu bắt buộc. Nêu rõ phiên bản của tài liệu OpenAPI (khác với phiên bản của tiêu chuẩn OAS và phiên bản triển khai API).
Hình 2: ví dụ về đối tượng info
8. Đối tượng Contact
Thông tin liên hệ cho API được tiếp xúc
Tên nhận dạng của người/ tổ chức liên hệ.
URL trỏ đến thông tin liên hệ và phải ở định dạng URL.
Địa chỉ email của người/ tổ chức liên hệ và phải ở định dạng địa chỉ email.
Hình 3: ví dụ về đối tượng contact
9. Đối tượng License
Để cung cấp thông tin giấy phép cho các API khác, đối tượng sẽ bao gồm:
Là trường dữ liệu bắt buộc. Tên loại giấy phép được sử dụng cho API.
URL của giấy phép được sử dụng cho API và phải ở định dạng URL.
Hình 4: ví dụ về đối tượng License
10. Đối tượng server
Các thông tin của đối tượng bao gồm:
Là trường dữ liệu bắt buộc. Một URL chỉ dẫn đến địa chỉ đích server. URL này hỗ trợ Biến máy chủ và có thể là tương đối, để chỉ ra rằng vị trí máy chủ có liên quan đến vị trí nơi tài liệu OpenAPI đang được cung cấp. Việc thay thế biến sẽ được thực hiện khi một biến được đặt tên trong {ngoặc }.
Một chuỗi tùy chọn mô tả máy chủ được chỉ định bởi URL. Cú pháp “CommonMark” có thể được sử dụng để biểu diễn văn bản đa dạng ngữ nghĩa.
Map[string, Server Variable Object]
Một ánh xạ giữa một tên biến và giá trị của nó. Giá trị được sử dụng để thay thế trong mẫu URL của máy chủ.
Hình 5: ví dụ về đối tướng server bao gồm nhiều máy chủ
11. Đối tượng variables của server
Một bảng liệt kê các giá trị chuỗi sẽ được sử dụng nếu các tùy chọn thay thế là từ một tập hợp giới hạn. Mảng giá trị này không được để trống.
Là trường dữ liệu bắt buộc. Giá trị mặc định để sử dụng thay thế, giá trị này sẽ được gửi nếu giá trị thay thế không được cung cấp. Nếu giá trị  “enum” được xác định, giá trị trường này nên tồn tại trong các giá trị của enum.
Trường giá trị này là tùy chọn cho biến máy chủ. Cú pháp “CommonMark” có thể được sử dụng để biểu diễn văn bản đa dạng thức.
12. Đối tượng Components
Đối tượng này có tác dụng giữ một tập hợp các đối tượng có thể tái sử dụng cho các khía cạnh khác nhau của OAS. Tất cả các đối tượng được xác định bên trong đối tượng thành phần sẽ không có hiệu lực trên API.
Map[string, Schema Object| Reference Object]
Là giá trị được tái sử dụng cho đối tượng Schema.
Map[string, Schema Object| Reference Object]
Là giá trị được tái sử dụng cho đối tượng Response.
Map[string, Schema Object| Reference Object]
Là giá trị được tái sử dụng cho đối tượng Parameter.
Map[string, Schema Object| Reference Object]
Là giá trị được tái sử dụng cho đối tượng Example.
Map[string, Schema Object| Reference Object]
Là giá trị được tái sử dụng cho đối tượng Request Body Objects.
Map[string, Schema Object| Reference Object]
Là giá trị được tái sử dụng cho đối tượng Header.
Map[string, Schema Object| Reference Object]
Là giá trị được tái sử dụng cho đối tượng Security Scheme.
Map[string, Schema Object| Reference Object]
Là giá trị được tái sử dụng cho đối tượng Link.
Map[string, Schema Object| Reference Object]
Là giá trị được tái sử dụng cho đối tượng Callback.
Tất cả các lĩnh vực cố định tuyên bố trên là đối tượng mà phải sử dụng các phím phù hợp với biểu thức chính quy: (^[a-zA-Z0-9\.\-_]+$).
13. Đối tượng Paths
Đối tượng Paths có tác dụng giữ các đường dẫn tương đối đến các điểm cuối riêng lẻ và hoạt động của chúng. Đường dẫn được nối vào URL từ đối tượng Server để tạo URL đầy đủ. Các đường dẫn có thể trống, do các ràng buộc ACL .
Mỗi đường dẫn thường đến một địa chỉ riêng lẻ. Tên trường phải bắt đầu bằng dấu gạch chéo lên (/). Đường dẫn được nối vào URL được mở rộng từ trường server của url để tạo URL đầy đủ. Tạo mẫu đường dẫn được cho phép. Khi các URL phù hợp, các đường dẫn cụ thể (không theo mẫu) sẽ được so sánh trước các đối tượng được tạo trước đó. Các đường dẫn không được để tên trùng nhau. Trong trường hợp so sánh không rõ ràng, tùy thuộc vào công cụ để quyết định sử dụng hay không.
14. Đối tượng Path Item
Mô tả các trường có sẵn trên một đường dẫn duy nhất. Đường dẫn có thể để trống do các ràng buộc ACL. Các trường của một đối tượng bao gồm:
Cho phép định nghĩa bên ngoài của mục đường dẫn này. Cấu trúc được tham chiếu phải ở định dạng Path Item.
Là trường không bắt buộc, nhằm áp dụng cho tất cả các thao tác trong đường dẫn.
Là trường không bắt buộc, nằm áp dụng cho tất cả các thao tác trong đường dẫn này.
Giá trị định nghĩa GET trong Path
Giá trị định nghĩa PUT trong Path
Giá trị định nghĩa POST trong Path
Giá trị định nghĩa DELETE trong Path
Giá trị định nghĩa OPTIONS trong Path
Giá trị định nghĩa HEAD trong Path
Giá trị định nghĩa PATCH trong Path
Giá trị định nghĩa TRACE trong Path
Một mảng giá trị “server” trong trường hợp thanh thế
[Parameter Object | Reference Object]
Danh sách các tham số có thể áp dụng cho tất cả các hoạt động được mô tả trong đường dẫn này. Các tham số này có thể được ghi đè ở mức hoạt động, nhưng không thể xóa ở đó. Danh sách KHÔNG ĐƯỢC bao gồm các tham số trùng lặp. Một tham số duy nhất được xác định bởi sự kết hợp của name và location. Danh sách có thể sử dụng Reference Object để liên kết đến các tham số được xác định tại các thành phần / tham số của Đối tượng OpenAPI.
15. Đối tượng Operation
Đối tượng Operation bao gồm:
Danh sách các thẻ để kiểm soát tài liệu API. Thẻ có thể được sử dụng để phân nhóm hợp lý các hoạt động theo tài nguyên.
Một bản tóm tắt ngắn về những gì hoạt động.
Giải thích chi tiết về hành vi hoạt động. Cú pháp CommonMark có thể được sử dụng để biểu diễn văn bản đa dạng thức.
Tài liệu bên ngoài bổ sung cho hoạt động này.
Chuỗi duy nhất được sử dụng để xác định hoạt động. Id phải là duy nhất trong số tất cả các hoạt động được mô tả trong API. Giá trị operationId phân biệt chữ hoa chữ thường. Các công cụ và thư viện có thể sử dụng operationId để xác định duy nhất một thao tác, do đó, khuyến cáo tuân theo các quy ước đặt tên chương trình phổ biến.
[Parameter Object | Reference Object]
Danh sách các thông số có thể áp dụng cho Operation được khai báo. Nếu một tham số đã được xác định tại mục Path item , thì định nghĩa mới sẽ ghi đè tham số đó nhưng không bao giờ có thể loại xóa bỏ nó. Danh sách không được chấp nhận bao gồm các tham số trùng lặp. Một tham số duy nhất được xác định bởi sự kết hợp của name và location. Danh sách có thể sử dụng Reference Object để liên kết đến các tham số được xác định tại các components/ parameter của đối tượng OpenAPI Object.
[Request Body Object | Reference Object]
“requestBody” được hỗ trợ trong các phương thức HTTP mà đặc điểm kỹ thuật HTTP 1.1 Tài liệu RFC7231 đã xác định rõ ràng ngữ nghĩa cho các nôi dụng được yêu cầu. Trong các trường hợp khác khi thông số HTTP không rõ ràng, “requestBody” sẽ bị bỏ qua.
Là trường dữ liệu bắt buộc. Là danh sách các responses có thể xảy ra khi chúng được trả về sau khi thực hiện các tháo tác tương đương.
Map[string, Callback Object | Reference Object]
Một bản đồ điển thị các lệnh gọi lại ngoài băng tần có thể liên quan đến hoạt động chính của operation. Đây là định danh duy nhất và các giá trị là duy nhất. mổ tả một yêu cầu có thể được khởi tạo bởi nhà cung cấp API và các phản hồi dự kiến.
Đây là một giá trị không còn được dùng nữa. người viết nên hạn chế sử dụng để khai báo. Giá trị mặc định là false.
Tuyên bố về các cơ chế bảo mật có thể được sử dụng cho hoạt động này. Danh sách các giá trị bao gồm các đối tượng yêu cầu bảo mật. Mỗi đối tượng là có yêu cầu bảo mật duy nhất. Để làm cho bảo mật là tùy chọn, một yêu cầu bảo mật trống ({}) có thể được bao gồm trong mảng. Định nghĩa này ghi đè mọi cấp cao nhất đã khai báo giá trị “security”. Để loại bỏ một khai báo bảo mật cấp cao nhất, một mảng trống có thể được sử dụng.
Mỗi giá trị “server” được thay thế cho tên duy nhất một server thật của Operation. Nếu một giá trị “server” bị thay thế thì nó sẽ bị ghi đè nếu được cấp phép bởi quyền cao nhất từ Operation.
16. Đối tượng Reference
Đối tượng Reference là Một đối tượng đơn giản để cho phép tham chiếu các thành phần khác trong đặc tả, bên trong và bên ngoài.
Đối tượng Tham chiếu được định nghĩa bởi tham chiếu JSON và tuân theo cùng một cấu trúc, hành vi và quy tắc.
Đối với đặc điểm kỹ thuật này, độ phân giải tham chiếu được thực hiện như được xác định theo đặc tả Reference JSON chứ không phải bởi đặc tả Schema JSON.
Trường cố định của đối tượng là
Là trường dữ liệu bắt buộc.
Đây là đối tượng không được mở rộng hay bổ sung, mọi thông tin, thuộc tính bổ sung sẽ bị bỏ qua.
Hình 6: ví dụ về đối tượng tham chiếu
17. Đối tượng schema
Đối tượng Schema cho phép định nghĩa các kiểu dữ liệu đầu vào và đầu ra. Những kiểu này có thể là đối tượng, nhưng cũng có thể là nguyên thủy và mảng. Đối tượng này là một tập con mở rộng của Đặc tả lược đồ JSON Wright Draft 00 .
Để biết thêm thông tin về các thuộc tính, hãy xem JSON Schema Core và JSON Schema Validation . Trừ khi được nêu khác đi, các định nghĩa thuộc tính tuân theo Schema JSON.
Tính chất của đối tượng có các thuộc tính sau được lấy trực tiếp từ định nghĩa của tài liệu Schema JSON và tuân theo các thông số kỹ thuật tương tự: title, multipleOf, maximum, exclusiveMaximum, minimum, exclusiveMinimum, maxLength, minLength, pattern, maxItems, minItems, uniqueItems, maxPropertis, minPropertis, required, enum
Các thuộc tính tiếp theo sẽ lấy trực tiếp từ định nghĩa của tài liệu Schema JSON nhưng chúng được điều chỉnh theo đặc tả OAS.
- type: Giá trị này phải là string. Nhưng loại giá trị thông qua mảng thì không được chấp nhận.
- allOf: Là một lượng đồ được tham chiếu phải thuộc đối tượng Schema và không phải là Schema JSON.
- oneOf: Là một lượng đồ được tham chiếu phải thuộc đối tượng Schema và không phải là Schema JSON.
- anyOf: Là một lượng đồ được tham chiếu phải thuộc đối tượng Schema và không phải là Schema JSON.
- not: Là một lượng đồ được tham chiếu phải thuộc đối tượng Schema và không phải là Schema JSON.
- items: giá trị này phải là một đối tượng và không phải là một mảng. Một lượng đồ được tham chiếu phải thuộc đối tượng Schema và không phải là Schema JSON.
- properties: các định nghĩa phải được tham chiếu phải thuộc đối tượng Schema và không phải là Schema JSON.
- additionalProperties: giá trị này có thể là Boolean hoặc một đối tượng cụ thể. Là một lượng đồ được tham chiếu phải thuộc đối tượng Schema và không phải là Schema JSON.
- description: Cú pháp CommonMark có thể được sử udjng để biểu diễn văn bản đa phương tiện.
- format: xem Data Type Formats để biết chi tiết. Các định dạng khác được xác định theo lượn đồ OAS hay JSON.
- default: là giá trị mặc định nếu người dùng không điền thông tin gì hay không cung cấp thông tin. Không giống như Lược đồ JSON, giá trị phải phù hợp với kiểu được xác định cho đối tượng schema được xác định ở cùng cấp. Ví dụ, nếu “type” là string, thì “default” có thể được "foo" nhưng không thể để là 1.
Kết thúc 2 phần, bài viết đã chia sẻ những khái niệm cơ bản nhất đến đi sâu vào các thành phần cấu thành quan trọng để xây dựng API dựa trên tiêu chuẩn OAS. Đây là cơ sở chia sẻ một cái nhìn tổng quan mà ngắn gọn cho người đọc về các khía cạnh của tiêu chuẩn OAS. Ngày nay, việc xây dựng và phát tiển API đã trở thành chìa khóa của công nghệ, từ đó hướng tới những giá trị cốt lỗi hơn các sản phẩm mà người sử dụng là trung tâm. Đây là tiêu chuẩn mở nhưng yếu tố uy tín đã được công nhận và được chứng minh là cơ sở cho các nhà phát triển, lập trình viên dựa vào đó làm căn cứ xuyên suốt quá trình xây dựng, phát triển ứng dụng sản phẩm.
Thông qua tiêu chuẩn OpenAPI Specification ver 3.0.3, ta có thêm khía cạnh xây dựng các API của chính phủ thuận tiện hơn cho người dân và doanh nghiệp sử dụng các dịch vụ hay chia sẻ kết nối thông tin.
Vũ Cao Minh Đức
Tài liệu tham khảo
- OpenAPI Specification ver 3.0.3 – swagger.io, February 2020.
- YAML Ain’t Markup Language (YAML™) Version 1.2, 3rd Edition, October 2019.
- JSON Schema: A Media Type for Describing JSON Documents draft-wright-json-schema-00, October 13th, 2016, A. Wright, Ed.
Quản trị viên, Cục Tin Học Hóa
Lần xem: 1579 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: 18945538
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.

OpenAPI Standard version 3.0.3 (OpenAPI Specification version 3.0.3) - Part II - Department of Computerization
Ministry of Information and Communications
The subordinate units
News - Events
Applying IT in the Agency


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 en 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 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 mật khẩu dùng một lần HOTP và TOTP
Thuật toán HOTP cung cấp một phương pháp xác thực bằng cách tạo đối xứng các mật khẩu hoặc giá trị mà người dùng có thể đọc được (làm một dãy số liên tục từ 6 -8 chữ số), mỗi một lần xác thực thì sẽ chỉ dùng duy nhất một mật khẩu. Mỗi lần tạo mật khẩu thì sẽ sử dụng duy nhất một giá trị bộ đếm, đây cũng là nền tảng xây dựng khái niệm một lần.
Các thành phần của thuật toán HOTP bao gồm:
Một phương pháp băm mật mã, kí hiệu là H (mặc định là SHA-1).
Một khóa bí mật, kí hiệu là K, là một chuỗi byte tùy ý và phải giữ nguyên trạng thái riêng tư, là giá trị bí mật được chia sẻ giữa người dùng và server.
Một bộ đếm, kí hiệu là C, là bộ đếm được đồng bộ giữa người dùng và server, độ dài của C là 8 bytes.
Độ dài giá trị HOTP, kí hiệu là d (thông thường độ dài từ 6–10, mặc định là 6 và 6–8 được khuyến nghị).
Cách sinh mật khẩu OTP trong thuật toán là:
Truncate( ): Là hàm tách chuỗi, lấy mật khẩu OTP từ việc thực hiện trích xuất kết quả từ hàm Hash.Hàm HMAC_SHA-1(K,C) có kết quả đầu ra cho một giá trị có độ dài là 160 bits = 20 bytes, hàm (Truncate) tách từ chuổi 160 bits thành một chuỗi mới có độ dài 32 bit, sau đó tính modulo để được mật khẩu OTP.
Lấy 4 bit thấp của byte cuối cùng từ kết quả đầu ra 160 bit của hàm HMAC_SHA1(K,C) chuyển sang cơ số 10 để tìm vị trí offset, sau đó sẽ được chuỗi 4 bytes = 32 bit tính từ vị trí offset.
Giá trị mật khẩu được tính theo công thức là:
HOTPvalue = HOTP(K,C) mod 10d
Để thực hiện quá trình sinh mã HOTP luôn cần một kênh liên lạc giữa người dùng và server để đảm bảo việc trao đổi giá trị K. Về phía server, server sẽ dựa vào giá trị K được trao đổi và giá trị bộ đếm C để sinh mật khẩu OTP. Về phía người dùng, người dùng sử dụng thiết bị tin cậy đã được kiểm chứng từ bên server để sinh một mã OTP. Trong quá trình xác thực cho người dùng, hai mã OTP được sinh ra từ phía server và phía người dùng sẽ được server so sánh với nhau, xác thực chỉ được xác nhận thành công nếu hai mãi OTP trùng nhau.
Vấn đề bảo mật
Trên thực tế sử dụng, HOTP vẫn luôn được coi là phương pháp bảo mật cho mật khẩu an toàn được nhiều công ty, tổ chức sử dụng. Tuy nhiên cốt lõi của nó luôn là vấn đề bảo mật nghiên trọng nhất và đó chính là SHA-1. HOTP từ thời điểm triển khai năm 2005 thì có sấp xỉ 5 năm thịnh hành, đến năm 2010, nhiều tổ chức đã khuyến nghị thay thế nó. Nhiều năm sau đó, SHA-1 dần bị trở nên lạc hậu và bị loại bỏ khỏi các giải thuật mật mã do độ dài mã của SHA-1 chỉ 160 bit dễ dàng bị giải mã bởi nhiều sự tiến bộ công nghệ, tốc độ giải mã nhanh hơn.
Từ năm 2020, SHA-1 luôn bị đe dọa bởi các Tấn công va chạm (Collision attack), đây là lí do Ars Technica, nhà phát triển sử dụng thư viện OpenSSH và Libssh khai tử không hỗ trợ hay sử dụng SHA-1 nữa. Trên thực tế từ năm 2020, SHA-1 gần như bị khai tử mở ra kỉ nguyên mới với SHA-2 và SHA-3.
Tiêu chuẩn mật khẩu dùng một lần TOTP
Tổng quan về TOTP
Mật khẩu dùng một lần dựa trên thời gian (TOTP) là một thuật toán máy tính tạo mật khẩu dùng một lần (OTP) sử dụng thời gian hiện tại làm nguồn duy nhất. Là một phần mở rộng của thuật toán Mật khẩu dùng một lần (HOTP). TOTP là nền tảng của Sáng kiến Xác thực Mở (OATH) và được sử dụng trong một số hệ thống xác thực hai yếu tố (2FA). Thông qua sự hợp tác của một số thành viên OATH, dự thảo TOTP đã được phát triển để tạo ra một tiêu chuẩn được ngành hỗ trợ. TOTP bổ sung cho HOTP tiêu chuẩn một lần dựa trên sự kiện và nó cung cấp cho các tổ chức và doanh nghiệp người dùng cuối nhiều sự lựa chọn hơn trong việc lựa chọn công nghệ phù hợp nhất với các yêu cầu ứng dụng và nguyên tắc bảo mật của họ. Năm 2008, OATH đã đệ trình phiên bản dự thảo của đặc điểm kỹ thuật cho IETF. Phiên bản này kết hợp tất cả các góp ý và đánh giá mà các tác giả nhận được từ cộng đồng kỹ thuật dựa trên các phiên bản trước được gửi cho Lực lượng Đặc nhiệm Kỹ thuật Internet (IETF). Vào tháng 5 năm 2011, TOTP chính thức trở thành tiêu chuẩn RFC 6238.
Phương thức xác thực TOTP
Để thực hiện xác thực TOTP, sau đấy là một quy trình ví dụ cụ thể để người dùng có thể xác thực và sử dụng một dịch vụ nào đó (theo thứ tự tăng dần):
Hình 1: Minh họa giao thức TOTP
1. Đối với người dùng lần đầu, người dùng đăng ký 2FA với nhà cung cấp dịch vụ của ứng dụng.
2. Nhà cung cấp một mã QR cho người dùng trên trình duyệt cá nhân.
3. Người dùng quét mã QR để được liên kết và tải về ứng dụng xác thực từ AppStore hoặc GoogleStore.
4. Người dùng sử dụng ứng dụng xác thực trên thiết bị cá nhân đáng tin cậy quét mã QR.
5. Sau khi quét mã QR người dùng được cấp mã OTP trên thiết bị đáng tin cậy và điền nó để truy cập ứng dụng.
Trên thực tế, TOTP là thuật toán dựa trên HOTP tức là tạo đối xứng các mật khẩu hoặc giá trị mà người dùng có thể đọc được (làm một dãy số liên tục từ 6 -8 chữ số), mỗi một lần xác thực thì sẽ chỉ dùng duy nhất một mật khẩu. Mỗi lần tạo mật khẩu thì sẽ sử dụng duy nhất một giá trị bộ đếm, tuy nhiên TOTP thay thế bộ đếm bằng một giá trị thời gian thực.
Xác thực và kích thước bước thời gian
OTP được tạo trong cùng một bước thời gian sẽ giống nhau. Khi một OTP được nhận tại một hệ thống xác thực, nó không biết dấu thời gian chính xác của người dùng khi một OTP được tạo. Hệ thống xác thực thường có thể sử dụng dấu thời gian khi nhận được OTP để so sánh OTP. Do độ trễ của mạng, khoảng cách (được đo bằng T, tức là số bước thời gian kể từ T0 ) giữa thời điểm OTP được tạo và thời gian OTP đến hệ thống nhận có thể lớn. Thời gian nhận tại hệ thống xác thực và quá trình tạo OTP thực tế có thể không nằm trong cùng một hiển thị bước thời gian tạo ra cùng một OTP. Khi OTP được tạo ở hiển thị cuối bước thời gian, thời gian nhận rất có thể rơi vào hiển thị bước thời gian tiếp theo. Hệ thống xác thực thường phải đặt chính sách cho cửa sổ trì hoãn truyền OTP có thể chấp nhận được để xác thực. Hệ thống xác thực phải so sánh các OTP không chỉ với dấu thời gian nhận mà còn với dấu thời gian trong quá khứ nằm trong độ trễ truyền. Do một số hiển thị được chấp nhận thời gian trì hoãn lớn hơn thời gian sẽ hiển thị cho một vụ tấn công của hacker nên nhà phát triển khuyến nghị rằng chỉ cho phép tối đa một bước thời gian vì độ trễ của mạng.
Kích thước bước thời gian có ảnh hưởng đến cả bảo mật và khả năng sử dụng. Kích thước bước thời gian lớn hơn có nghĩa là cửa sổ hiệu lực lớn hơn để OTP được chấp nhận bởi hệ thống xác thực. Có những tác động khi sử dụng kích thước bước thời gian lớn hơn, như sau:
Thứ nhất, kích thước bước thời gian hiển thị càng lớn thì nguy cơ tấn công càng cao. Khi OTP được tạo và hiển thị với bên thứ ba trước khi nó được sử dụng, bên thứ ba có thể sử dụng OTP trong hiển thị cùng bước thời gian, vì vậy bên phát triển đề xuất kích thước bước thời gian mặc định là 30 giây này nhằm để cân bằng giữa bảo mật và khả năng sử dụng.
Thứ hai, OTP khác tiếp theo phải được tạo trong hiển thị ở bước thời gian tiếp theo. Người dùng phải đợi cho đến khi đồng hồ chuyển sang hiển thị bước thời gian tiếp theo từ lần gửi cuối cùng. Thời gian chờ có thể không chính xác bằng độ dài chuyển tiếp của hiển thị tiếp theo, tùy thuộc vào thời điểm tạo OTP cuối cùng. Ví dụ: nếu OTP cuối cùng được tạo ở thời điểm nửa chừng trong hiển thị bước thời gian, thì thời gian chờ cho OTP tiếp theo bằng một nửa thời gian của bước thời gian. Nói chung, hiển thị với bước thời gian lớn hơn có nghĩa là thời gian chờ lâu hơn để người dùng nhận được OTP hợp lệ tiếp theo sau lần xác thực OTP thành công cuối cùng. Một hiển thị với thời gian chờ quá lớn (ví dụ: 10 phút) có lẽ sẽ không phù hợp với các trường hợp sử dụng đăng nhập Internet điển hình; người dùng có thể không nhận được mã OTP tiếp theo trong vòng 10 phút và do đó sẽ phải đăng nhập lại vào cùng một trang web sau 10 phút.
Vấn đề bảo mật
Cũng giống với HOTP, TOTP cũng sử dụng SHA-1 và trở nên lỗi thời từ năm 2020. Tuy nhiên do không sử dụng bộ đếm C (có thể tính toán được) mà thay thế bằng thời gian thực và được tính toán cụ thể nên TOTP vẫn đủ an toàn với thời gian thực vừa đủ để chống lại cuộc tấn công từ bên thứ 3.
Vấn đề thời gian cũng là hạn chế bảo mật của TOTP, việc hiển thị OTP quá lâu sẽ gây ra sự mất an toàn cho cả người dùng và server. Ngược lại thì thời gian hiển thị quá ngắn khiến cho TOTP cũng gây ra sự bất tiện cho người dùng.
Tuy nhiên khi được xếp vào nhóm các giải pháp bảo mật hai yếu tố (2FA) thì việc xác thực TOTP vẫn được ưa chuộng bởi tính hiệu quả về thời gian thực và an toàn với thời gian sinh OTP.
Trong bài viết này, hai tiêu chuẩn mật khẩu dùng một lần HOTP và TOTP được giới thiệu một cách khái quát đến cụ thể thuật toán sinh mật khẩu để người đọc có hình dung về phương thức tạo và xác thực với mật khảu dùng một lần. Trong thực tế phát triển của thế giới hiện nay thì cả hai tiêu chuẩn đều đã có những dấu ấn trong phát triển bảo mật và an toàn mật khẩu cho người dùng trong nhiều lĩnh vực, điển hình nhất là thanh toán trực tuyến, xác thực người dùng, mặc dù HOTP có phần lỗi thời nhưng với những sự chỉnh sửa kết hợp công nghệ mới hiện nay thì TOTP vẫn được ứng dụng trong bảo đảm an toàn mật khẩu OTP.
Thông qua việc giới thiệu hai 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 bảo mật và an toàn thông tin trong mật khẩu nhằm xác thực tài khoản, xác thực người dùng. Đồng thời, trong bối cảnh phát triển theo xu hướng công nghệ cao phục vụ người dân, cơ quan nhà nước và đặc biệt là phát triển chính phủ điện tử, thì việc ứng dụng các công nghệ an toàn bảo mật đặc biệt với mật khẩu OTP là vô cùng cần thiết, đây là yếu tố cơ bản cho thanh toán hay xác thực trực tuyến tại Việt Nam hiện nay.
Vũ Cao Minh Đức
Tài liệu tham khảo
RFC 4226: “HOTP: An HMAC-Based One-Time Password Algorithm”, IETF, D. M'Raihi (VeriSign), M. Bellare (UCSD), F. Hoornaert (Vasco), D. Naccache (Gemplus), O. Ranen (Aladdin), December 2005.
RFC 6238: “TOTP: Time-Based One-Time Password Algorithm”, IETF, ISSN: 2070 – 1721, D. M'Raihi (Verisign, Inc.), S. Machani (Diversinet Corp.), M. Pei (Symantec), J. Rydell (Portwise, Inc.), May 2021.
Quản trị viên, Cục Tin Học Hóa
Lần xem: 1390 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 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)
Giới thiệu giao thức truy cập an toàn không dây Wi-Fi thế hệ thứ 3 ( 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: 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.

--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 vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi vi es 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 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
Một số chính sách và quy định pháp lý phát triển Chính phủ số của Bỉ (Phần 2)
Phần 2. Các yếu tố cốt lõi trong chiến lược phát triển và một số quy định pháp lý căn bản Trong phần 1, bài viết đã giới thiệu những nội dung căn bản trong các chiến lược phát triển chính phủ số của Bỉ, nội dung bài 2 sẽ đề cập tới một số yếu tố cốt lõi trong các chiến lược góp phần tạo sự phát triển đột phá và giới thiệu một số quy định pháp lý căn bản như định danh điện tử, chữ ký điện tử của Bỉ.
Chiến lược phát triển và một số yếu tố quan trọng
Chiến lược số của Wallonia và Liên bang Wallonia-Brussels
Chiến lược số của Wallonia đã được Chính quyền Walloon và Cộng đồng Pháp thông qua vào tháng 12 năm 2015. Chiến lược đánh dấu tham vọng của Chính quyền Walloon là biến Wallonia thành một lãnh thổ được kết nối và thông minh, các công ty công nghệ được công nhận là những nhà lãnh đạo toàn cầu và là động lực thúc đẩy quá trình chuyển đổi thành công của khu vực. Chiến lược kỹ thuật số của Wallonia là một trong những đóng góp chính trong việc tạo ra Digital Wallonia. Chiến lược bao gồm năm chủ đề chính để đạt được tham vọng Wallonia số.
Mỗi chủ đề được cấu trúc thành các mục tiêu chiến lược và trục phát triển. Người ta hy vọng rằng thông qua sự bổ sung và tương tác này, các chủ đề, mục tiêu và trục phát triển sẽ thúc đẩy quá trình chuyển đổi số ở Wallonia.
- Kinh tế số (economy of the numeric, economy of the digital): chủ đề này tập trung vào việc tạo ra lĩnh vực công nghệ mạnh thông qua chương trình tăng trưởng nhằm mục đích đưa lĩnh vực kỹ thuật số của Wallonia lên tầm quốc tế; tập trung vào việc tăng khả năng kỹ thuật số của các doanh nghiệp, điều cần thiết cho sự phát triển thương mại kết nối.
- Lãnh thổ được kết nối và thông minh: chủ đề này nhằm đạt được kết nối tốc độ cao đầy đủ ở Wallonia.
- Tiện ích mở: chủ đề này nhằm thúc đẩy các dịch vụ hành chính công trực tuyến công khai và minh bạch.
- Kỹ năng và việc làm: chủ đề này tập trung vào việc phát triển các kỹ năng kỹ thuật số của người dân Wallonia.
Chính phủ Walloon đã dành hơn 500 triệu EUR để thực hiện chiến lược trong thời gian 4 năm.
Chiến lược chính phủ điện tử của Flanders
Tại Khu vực Flemish, chiến lược Chính phủ điện tử do Thứ trưởng – Trưởng vùng Flemish phụ trách, được quản lý bởi Cơ quan Thông tin Flanders mới được thành lập vào năm 2015 thông qua sự hợp nhất của cơ quan Chính phủ điện tử Flemish,  Trung tâm tiếp nhận, giải đáp cho người dân Vlaamse Infolijn và Cơ quan Thông tin Địa lý Flanders và một phần của Bộ Hành chính. Cơ quan mới này chịu trách nhiệm về chương trình Chính phủ điện tử mới nhằm mục đích cung cấp dịch vụ của Chính quyền Flemish hoàn toàn trên môi trường số vào năm 2020 và bảo đảm thực hiện nguyên tắc thu thập dữ liệu một lần duy nhất được toàn bộ chính quyền Flemish thừa nhận.
Trách nhiệm chính của Cơ quan Thông tin Flanders là xác định các mục tiêu chiến lược và ưu tiên cho việc chuyển đổi chính phủ Flemish thành một chính phủ dựa trên dữ liệu, đồng thời tham gia vào các dự án Chính phủ điện tử với vai trò cố vấn và hỗ trợ. Cơ quan này cũng chịu trách nhiệm phát triển kiến thức và kỹ năng liên quan đến Chính phủ điện tử, điều phối và cung cấp các biện pháp khuyến khích, đồng thời tạo ra một cơ sở hạ tầng chung cho Chính phủ điện tử để tạo điều kiện hợp tác giữa các thực thể khác nhau trong chính quyền Flanders. Cơ sở hạ tầng chung của Chính phủ điện tử này bao gồm một số mảnh ghép chính phủ điện tử như dịch vụ định danh điện tử, tài liệu điện tử, eProcurement,…  có thể được sử dụng làm hệ thống dùng chung nhằm cải thiện việc cung cấp dịch vụ hiện tại và hợp lý hóa hoạt động của chính phủ.
Một số yếu tố chính sách quan trọng trong chính sách Chính phủ điện tử này là sự phát triển các nguồn thông tin xác thực. Đây là những cơ sở dữ liệu có thể được sử dụng để thu thập dữ liệu đầy đủ, chính xác và cập nhật về doanh nghiệp, cá nhân, địa chỉ, lô đất, tòa nhà, bản đồ,… Một hệ thống toàn diện gồm các nguồn dữ liệu xác thực Flemish và các dịch vụ liên quan hiện đang được xây dựng. Song song với đó, một cơ sở hạ tầng dựa trên kiến trúc SOA được gọi là nền tảng MAGDA đã được ra mắt năm 2006 cho phép tích hợp các dịch vụ trao đổi dữ liệu của chính phủ và tạo điều kiện cho cả việc truy cập vào các nguồn dữ liệu xác thực và trao đổi dữ liệu giữa các cơ quan. Năm 2013, việc triển khai nền tảng MAGDA 2.0 đã được hoàn thành, một phiên bản mới của nền tảng cung cấp các phương tiện trao đổi dữ liệu bổ sung (dịch vụ web, truyền tệp,… ), đồng thời yêu cầu chi phí hoạt động thấp hơn. Năm 2017, nền tảng rất thành công này được chuyển đổi sang môi trường Cloud.
Trong Chiến lược Chính phủ điện tử của Flemish giai đoạn 2009-2014, Bộ trưởng Flemish chịu trách nhiệm về Chính phủ điện tử đã kêu gọi tập trung nỗ lực phát triển các giải pháp tích hợp, góp phần đơn giản hóa thủ tục hành chính và tăng hiệu quả hoạt động của chính phủ. Trong đó, đáng chú ý là việc tạo ra các nguồn dữ liệu xác thực và quan tâm cụ thể đối với vấn đề tham gia điện tử (eParticipation), ICT xanh và việc sử dụng dữ liệu mở. Một thách thức quan trọng trong giai đoạn này là mở rộng các dịch vụ Chính phủ điện tử back-end do nền tảng MAGDA cung cấp cho tất cả các cấp chính quyền địa phương.
Trong Chiến lược Chính phủ điện tử mới của Flemish giai đoạn 2014-2019, Bộ trưởng Flemish chịu trách nhiệm về Chính phủ điện tử là Liesbeth Homans, mục đích là “chuyển đổi số hoàn toàn” chính quyền Flemish với cách tiếp cận digital first trong việc cung cấp các dịch vụ của chính quyền Flemish, trong đó tăng cường cung cấp trên di động. Trong quá trình chuyển đổi này, trọng tâm là cách tiếp cận lấy người dân làm trung tâm trong việc thiết kế các dịch vụ số và phát triển các mảnh ghép Chính phủ điện tử mới (chẳng hạn như Cổng thông tin cá nhân hóa cho người dân và doanh nghiệp) sẽ được cung cấp cho các cấp chính quyền địa phương. Dữ liệu mở sẽ là tiêu chuẩn nếu có liên quan đến tính sẵn có và khả năng sử dụng lại dữ liệu của chính phủ.
Hình 1: Tỷ lệ người dân gửi biểu mẫu dữ liệu điện tử tới các cơ quan khu vực công để giải quyết TTHC tại Bỉ
Chiến lược Chính phủ điện tử của Vùng Thủ đô Brussels
Tháng 5 năm 2014, sau cuộc bầu cử, Chính phủ đã công bố chính sách của mình. Điểm nổi bật bao gồm:
- Thành phố thông minh Brussels: Đưa Brussels trở thành Thủ đô kỹ thuật số;
- Tiến xa nhất có thể trong việc quản lý hành chính trực tuyến;
- Giải quyết các điểm nóng giao thông công cộng;
- Mở rộng và đơn giản hóa bộ phận một cửa.
Một số yếu tốt cốt lõi trong các định hướng chiến lược
Thứ nhất, Truy cập thông tin dùng chung
Chiến lược dữ liệu mở 2015-2020
Tháng 7 năm 2015, Phó Thủ tướng kiêm Bộ trưởng Chương trình kỹ thuật số và Viễn thông Alexander De Croo đã thông báo về việc áp dụng chiến lược dữ liệu mở cho Bỉ nhằm tăng cường hệ sinh thái kỹ thuật số và sự phát triển theo hướng quản trị tinh gọn, hiệu quả và hiện đại hơn. Phần quan trọng nhất của kế hoạch là tạo mặc định cho tất cả dữ liệu của chính phủ, ngoại trừ thông tin có liên quan đến quyền riêng tư hoặc bảo mật.
Điều lệ sử dụng dữ liệu mở theo thẩm quyền của địa phương
Sáng kiến Smart Flanders chấp nhận Điều lệ về dữ liệu mở, một dự án bao gồm 20 nguyên tắc như dữ liệu mở theo mặc định và máy có thể đọc được để chính quyền địa phương có thể thúc đẩy một hệ sinh thái dữ liệu mở.
Điều lệ Dữ liệu Mở đã được phê duyệt vào mùa hè năm 2018 và được 13 thành phố Flemish phê chuẩn. Để đưa Điều lệ vào thực tiễn, một tài liệu chuyên môn sâu đã được phát triển với các điều khoản mẫu có thể được sử dụng trong đấu thầu, đàm phán và hợp đồng để thỏa thuận với các nhà cung cấp về Dữ liệu mở. Việc sử dụng các công thức này được khuyến nghị để cố gắng đạt được cách tiếp cận chung hơn đối với Dữ liệu mở.
Thứ hai, tương hợp. Nội dung bảo đảm tương hợp có thể kể tới Khung tương hợp quốc gia BelgIF và Chiến lược Văn phòng Chuyển đổi số. Trong Cơ quan Chính sách và hỗ trợ dịch vụ công mới được thành lập, Văn phòng chuyển đổi kỹ thuật số  triển khai Chương trình kỹ thuật số của Bỉ, dựa trên Chương trình kỹ thuật số năm 2020 của Châu Âu.
Chức năng và Dịch vụ chính của Văn phòng Chuyển đổi Kỹ thuật số là:
- Hỗ trợ chính phủ liên bang số hóa;
- Trở thành động lực cho sự đổi mới và chuyển đổi số của chính phủ liên bang;
- Tư vấn về công nghệ và dự án từ quan điểm lấy doanh nghiệp và người dân làm trung tâm.
Các dịch vụ chính của Văn phòng Chuyển đổi Kỹ thuật số là:
- Phát triển chiến lược và tiêu chuẩn kỹ thuật số cho chính phủ liên bang;
- Thực thi và giám sát quá trình chuyển đổi kỹ thuật số của chính phủ liên bang;
- Phát triển các dịch vụ và nền tảng số xuyên suốt như dịch vụ Truyền thông số, Dịch vụ vận hành và Cơ sở hạ tầng;
- Giám sát hội đồng chiến lược G-Cloud và các ủy ban trong khi báo cáo với chính phủ liên bang.
Ngoài các yếu tố trên, một số yếu tố khác như: eID và dịch vụ tin cậy; An toàn, an ninh thông tin liên quan tới chính phủ số; Mua sắm chính phủ eProcurement và một số chiến lược, kế hoạch hành động về AI, G-Cloud,…
Pháp lý cho Chính phủ số
Khung quản trị chính sách kỹ thuật số và công nghệ thông tin
Ngày 25 tháng 10 năm 2018, Nghị viện của Cộng đồng Pháp đã thông qua pháp lý quan trọng về khung quản trị chính sách kỹ thuật số và công nghệ thông tin. Khung bao gồm một số pháp lý quan trọng như:
- Xác định các nguyên tắc chung cho việc chuyển đổi chính phủ số;
- Thành lập một hội đồng chiến lược về chuyển đổi số;
- Tạo cơ sở pháp lý cho các cơ cấu quản trị;
- Thiết lập một kế hoạch chiến lược để phát triển kỹ thuật số và CNTT (hiệu lực trong 5 năm).
Luật về định danh điện tử
Luật về định danh điện tử được ban hành năm 2017, đã hoàn thiện quy định eIDAS. Theo luật này, các thủ tục sau được áp dụng:
- Mỗi cơ quan khu vực công của Bỉ xác định mức độ đảm bảo cần thiết để truy cập vào các dịch vụ của mình và thông báo cho Văn phòng chuyển đổi số về điều này;
- Văn phòng Chuyển đổi số xác định mức độ đảm bảo của phương tiện định danh điện tử của Bỉ sẽ được thông báo cho Ủy ban Châu Âu và thông báo cho các nhà cung cấp dịch vụ định danh điện tử của Bỉ;
- Văn phòng Chuyển đổi số được chỉ định là Trung tâm trao đổi CNTT xuyên biên giới của Bỉ và đã chuyển một bộ dữ liệu nhận dạng cá nhân tối thiểu tới điểm của quốc gia thành viên khác khi người dùng muốn truy cập vào dịch vụ trực tuyến tại quốc gia thành viên đó.
Để kích hoạt tính năng định danh di động, tháng 10 năm 2017 Cơ quan Chính sách và hỗ trợ dịch vụ công đã ban hành Nghị định, trong đó đưa ra các quy tắc quản lý việc công nhận các dịch vụ định dnah điện tử tư nhân và dịch vụ di động nói riêng. Làm việc với các đối tác tư nhân cho phép Chính phủ kiểm soát chi phí và thúc đẩy đổi mới. Các dịch vụ định danh bên ngoài này do các công ty tư nhân phát triển và vận hành.
Luật về chữ ký điện tử và khung khổ pháp lý cho định danh điện tử
Luật được thông qua vào ngày 9 tháng 7 năm 2001, mang lại giá trị pháp lý cho chữ ký điện tử và các văn bản được ký điện tử đồng thời thiết lập một khuôn khổ pháp lý cho các dịch vụ chứng nhận. Điều đáng nói là ở cấp độ khu vực, luật về các biểu mẫu điện tử được ký kết với thẻ eID vào tháng 12 năm 2006 và hai Nghị định liên quan vào tháng 7 năm 2008 đã được Nghị viện Walloon và Chính quyền Walloon lần lượt thông qua. Các Nghị định này đã mang lại giá trị pháp lý cho biểu mẫu điện tử giá trị như biểu mẫu giấy.
Hơn nữa, khuôn khổ pháp lý cho việc sử dụng chứng minh thư điện tử đã được đặt ra trong một loạt các Nghị định, cụ thể là: Nghị định về khuôn khổ pháp lý của thẻ căn cước điện tử; Nghị định về định dạng thẻ căn cước điện tử; Nghị định về việc tổng quát hóa thẻ ID điện tử và Nghị định về tài liệu eID cho trẻ em Bỉ dưới 12 tuổi.
Các chiến lược phát triển và khung khổ pháp lý trên đã tạo nền tảng vững chắc cho việc chuyển đổi số xây dựng Chính phủ số tại Vương quốc Bỉ, nâng thứ hạng phát triển của Bỉ trong khu vực chung Châu Âu và thúc đẩy phát triển kinh tế dựa trên công nghệ số.
- Chương trình ISA ủy ban Châu Âu.
Quản trị viên, Cục Tin Học Hóa
Lần xem: 358 Go top
Thị trường chuyển đổi số ở một số quốc gia trên thế giới ( 29/09/2022)
Chuyển đổi số lĩnh vực điển hình: Kinh nghiệm chuyển đổi số lĩnh vực giáo dục tại Thụy Điển ( 29/09/2022)
Một số kinh nghiệm, và câu chuyện điển hình về chuyển đổi số trên thế giới: Chuyển đổi số tại công ty bán lẻ WalMart ( 29/09/2022)
Một số kinh nghiệm và câu chuyện điển hình về chuyển đổi số trên thế giới: Chuyển đổi số tại công ty trong lĩnh vực sản xuất đồ uống ( 28/09/2022)
Chuyển đổi số lĩnh vực điển hình: Kinh nghiệm chuyển đổi số lĩnh vực y tế tại Thụy Điển ( 28/09/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)
Đẩ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.