• Hiểu đúng về phân quyền - MDE - SQL Backend
  • Hiểu đúng về phân quyền - MDE - SQL Backend

    ckno1no > 26-07-16, 03:05 PM

    Xin chào cả nhà,

    Mình lập chủ đề này, mong muốn được hiểu rõ hơn về các cơ chế thiết kế 1 phần mềm/ ứng dụng Access tốt, liên quan chủ yếu tới vấn đề bảo mật và sử dụng dữ liệu. 

    Mình đã đọc các bài viết liên quan trong diễn đàn, qua các bài đọc này, mình rút ra được 1 số nhận định và xin được viết ra. Mong các bạn có thể giúp mình hiểu đúng hơn các nhận định này, hoặc nếu mình đang hiểu sai thì giúp mình hiểu đúng nhé.

    Theo như mình tìm hiểu ở trên diễn đàn thì để có được 1 phần mềm chạy Access hiệu quả về tốc độ và bảo mật, cần thiết kế theo kiểu Front-end và Back-end. Trong đó: 
    • Frontend-Access: nơi người dùng tương tác với các forms và reports bằng những nghiệp vụ như nhập, sửa, xóa, xem, in báo cáo, ... 
    • Backend-Sql: nơi lưu trữ dữ liệu, Front-end sẽ liên kết với Backend bằng các linked tables, phương pháp kết nối dùng cổng ODBC.
    Phương pháp này thậm chí cho phép người dùng sử dụng phần mềm dù không ở trong mạng LAN (ở ngoài chi nhánh cũng có thể kết nối và sử dụng phần mềm, chung database với trụ sở).

    Khi dùng Access 2003 thì Microsoft hỗ trợ chức năng phân quyền người dùng (User-level Security) cho phép phân quyền theo nhóm, hạn chế khả năng nhập dữ liệu, sửa dữ liệu, xóa dữ liệu và cả sửa thiết kế (design). Từ 2007 trở đi, không còn chức năng này nữa nên muốn phân quyền người dùng thì phải tự lập trình.

    Phân quyền có 2 loại: 
    • Phân quyền tổng quát: quy định từng nhóm đối tượng được phép truy cập vào forms hoặc reports nào của phần mềm như bài này: http://thuthuataccess.com/forum/thread-71.html của bạn Noname.
    • Phân quyền chi tiết: quy định từng nhóm đối tượng được phép thực hiện nghiệp vụ gì trong 1 form: nhập, sửa, xóa dữ liệu.
    Đối với việc phân quyền sửa thiết kế (design) như hạn chế người dùng xem, sửa thiết kế của forms hay reports hoặc cả querries thì phải chuyển file từ MDB sang MDE. Đây là phương pháp bảo vệ trí tuệ tốt nhất hiện tại.

    Để hạn chế khả năng thao tác lên dữ liệu và thiết kế của phần mềm, thì có thể dùng thủ thuật giấu ribbon (2007) hoặc Menu bar (2003) khi phần mềm vừa mở.


    ---
    Còn 1 số thắc mắc sau khi đọc các bài viết trên diễn đàn và không tìm thấy câu trả lời, mình mạn phép hỏi thêm ở đây, mong được chỉ dẫn:
    • Ngoài phương pháp chuyển file MDE, còn có phương pháp nào hạn chế người dùng tiếp cận thiết kế (forms, querries, reports) của phần mềm không?
    • SQL cho phép bảo mật thông tin cơ sở dữ liệu rất tốt. Tuy nhiên, các dữ liệu này lại được liên kết với Front end ở dạng Linked tables nên người dùng (nếu có chút hiểu biết) chỉ cần nhấn F11 có thể mở được Navigation Pane, xong từ đó có thể thấy các linked tables (ở SQL Backend-database). Khi thấy được là sao chép được, và lấy được dữ liệu. Như vậy không thể hạn chế việc này?
  • RE: Hiểu đúng về phân quyền - MDE - SQL Backend

    hoanbhxhls > 26-07-16, 03:20 PM

    (26-07-16, 03:05 PM)ckno1no Đã viết: Xin chào cả nhà,

    Mình lập chủ đề này, mong muốn được hiểu rõ hơn về các cơ chế thiết kế 1 phần mềm/ ứng dụng Access tốt, liên quan chủ yếu tới vấn đề bảo mật và sử dụng dữ liệu. 

    Mình đã đọc các bài viết liên quan trong diễn đàn, qua các bài đọc này, mình rút ra được 1 số nhận định và xin được viết ra. Mong các bạn có thể giúp mình hiểu đúng hơn các nhận định này, hoặc nếu mình đang hiểu sai thì giúp mình hiểu đúng nhé.

    Theo như mình tìm hiểu ở trên diễn đàn thì để có được 1 phần mềm chạy Access hiệu quả về tốc độ và bảo mật, cần thiết kế theo kiểu Front-end và Back-end. Trong đó: 
    • Frontend-Access: nơi người dùng tương tác với các forms và reports bằng những nghiệp vụ như nhập, sửa, xóa, xem, in báo cáo, ... 
    • Backend-Sql: nơi lưu trữ dữ liệu, Front-end sẽ liên kết với Backend bằng các linked tables, phương pháp kết nối dùng cổng ODBC.
    Phương pháp này thậm chí cho phép người dùng sử dụng phần mềm dù không ở trong mạng LAN (ở ngoài chi nhánh cũng có thể kết nối và sử dụng phần mềm, chung database với trụ sở).

    Khi dùng Access 2003 thì Microsoft hỗ trợ chức năng phân quyền người dùng (User-level Security) cho phép phân quyền theo nhóm, hạn chế khả năng nhập dữ liệu, sửa dữ liệu, xóa dữ liệu và cả sửa thiết kế (design). Từ 2007 trở đi, không còn chức năng này nữa nên muốn phân quyền người dùng thì phải tự lập trình.

    Phân quyền có 2 loại: 
    • Phân quyền tổng quát: quy định từng nhóm đối tượng được phép truy cập vào forms hoặc reports nào của phần mềm như bài này: http://thuthuataccess.com/forum/thread-71.html của bạn Noname.
    • Phân quyền chi tiết: quy định từng nhóm đối tượng được phép thực hiện nghiệp vụ gì trong 1 form: nhập, sửa, xóa dữ liệu.
    Đối với việc phân quyền sửa thiết kế (design) như hạn chế người dùng xem, sửa thiết kế của forms hay reports hoặc cả querries thì phải chuyển file từ MDB sang MDE. Đây là phương pháp bảo vệ trí tuệ tốt nhất hiện tại.

    Để hạn chế khả năng thao tác lên dữ liệu và thiết kế của phần mềm, thì có thể dùng thủ thuật giấu ribbon (2007) hoặc Menu bar (2003) khi phần mềm vừa mở.


    ---
    Còn 1 số thắc mắc sau khi đọc các bài viết trên diễn đàn và không tìm thấy câu trả lời, mình mạn phép hỏi thêm ở đây, mong được chỉ dẫn:
    • Ngoài phương pháp chuyển file MDE, còn có phương pháp nào hạn chế người dùng tiếp cận thiết kế (forms, querries, reports) của phần mềm không?
    • SQL cho phép bảo mật thông tin cơ sở dữ liệu rất tốt. Tuy nhiên, các dữ liệu này lại được liên kết với Front end ở dạng Linked tables nên người dùng (nếu có chút hiểu biết) chỉ cần nhấn F11 có thể mở được Navigation Pane, xong từ đó có thể thấy các linked tables (ở SQL Backend-database). Khi thấy được là sao chép được, và lấy được dữ liệu. Như vậy không thể hạn chế việc này?
    -Dùng ADO để kết nối sql server thì không cần sử dụng link table
    -Tất cả các thuật toán truy vấn dữ liệu đưa hết vào code thì không cần dùng query
    -File mdb front end chỉ có form và report,module sau đó dịch sang mde thì đảm bảo an toàn luôn
  • RE: Hiểu đúng về phân quyền - MDE - SQL Backend

    ckno1no > 26-07-16, 03:41 PM

    (26-07-16, 03:20 PM)hoanbhxhls Đã viết: -Dùng ADO để kết nối sql server thì không cần sử dụng link table
    -Tất cả các thuật toán truy vấn dữ liệu đưa hết vào code thì không cần dùng query
    -File mdb front end chỉ có form và report,module sau đó dịch sang mde thì đảm bảo an toàn luôn

    Cám ơn bạn nhé,

    "Thuật toán truy vấn đưa hết vào code" tức là bạn đang nói về module (class) ở Access phải không?

    Nếu như vậy không dùng linked tables, mỗi một form, tức là truy xuất từng table lưu trên SQL Server sẽ phải viết từng modules, class để truy xuất. Nếu database có khoảng 40-50 bảng dữ liệu thì quả thật việc viết class và module là quá nhiều?

    Mình cũng đang tìm 1 bản demo cách thức này trên diễn đàn (có backend SQL, frontend Access, kết nối ADO, và vài câu lệnh code viết vào module đơn giản như truy xuất dữ liệu) nhưng không tìm thấy, bạn có thể giúp mình không?
  • RE: Hiểu đúng về phân quyền - MDE - SQL Backend

    maidinhdan > 26-07-16, 05:33 PM

    (26-07-16, 03:05 PM)ckno1no Đã viết: ---
    Còn 1 số thắc mắc sau khi đọc các bài viết trên diễn đàn và không tìm thấy câu trả lời, mình mạn phép hỏi thêm ở đây, mong được chỉ dẫn:
    • Ngoài phương pháp chuyển file MDE, còn có phương pháp nào hạn chế người dùng tiếp cận thiết kế (forms, querries, reports) của phần mềm không?
    • SQL cho phép bảo mật thông tin cơ sở dữ liệu rất tốt. Tuy nhiên, các dữ liệu này lại được liên kết với Front end ở dạng Linked tables nên người dùng (nếu có chút hiểu biết) chỉ cần nhấn F11 có thể mở được Navigation Pane, xong từ đó có thể thấy các linked tables (ở SQL Backend-database). Khi thấy được là sao chép được, và lấy được dữ liệu. Như vậy không thể hạn chế việc này?

    Cùng tung tăng vài dòng cùng bạn nhé, chỉ trích lại chỗ nào cần thôi.

    Trích dẫn:1. Backend-Sql: nơi lưu trữ dữ liệu, Front-end sẽ liên kết với Backend bằng các linked tables, phương pháp kết nối dùng cổng ODBC.

    Bạn nói thiếu rồi: Dùng DAO hoặc DAO không cần Linktable cũng được.


    Trích dẫn:2. Đối với việc phân quyền sửa thiết kế (design) như hạn chế người dùng xem, sửa thiết kế của forms hay reports hoặc cả querries thì phải chuyển file từ MDB sang MDE. Đây là phương pháp bảo vệ trí tuệ tốt nhất hiện tại.

    Ngoài phương pháp chuyển file MDE, còn có phương pháp nào hạn chế người dùng tiếp cận thiết kế (forms, querries, reports) của phần mềm không?


    Không cần thiết đến nổi phải dùng đến MDB, chỉ cần đặt pass có độ dài hợp lý và ký tự đặt biệt là không có một phần nào nảo bẻ khó@ để xem cái code của bạn được đâu.

    Trích dẫn:3. Để hạn chế khả năng thao tác lên dữ liệu và thiết kế của phần mềm, thì có thể dùng thủ thuật giấu ribbon (2007) hoặc Menu bar (2003) khi phần mềm vừa mở.

    SQL cho phép bảo mật thông tin cơ sở dữ liệu rất tốt. Tuy nhiên, các dữ liệu này lại được liên kết với Front end ở dạng Linked tables nên người dùng (nếu có chút hiểu biết) chỉ cần nhấn F11 có thể mở được Navigation Pane, xong từ đó có thể thấy các linked tables (ở SQL Backend-database). Khi thấy được là sao chép được, và lấy được dữ liệu. Như vậy không thể hạn chế việc này?

    2 ý trên có cùng nội dung nên minh để chung để trả lời.

    Xem ý số 1 mình viết và bổ sung thêm là dùng thuật toán mã hóa các cột của table khi kết nối bằng Link table mà không phải là ADO hoặc DAO.


    Thân mến!
  • RE: Hiểu đúng về phân quyền - MDE - SQL Backend

    ckno1no > 27-07-16, 09:48 AM

    Maidinhdan ơi, 

    Trước tiên cám ơn bạn vì đã nhiệt tình "tung tăng" cùng,

    Kế tiếp là, mình chỉ mới đọc và tìm hiểu trên diễn đàn để rút ra nhận định nên thấy bản thân vẫn còn yếu chuyên môn lắm. 

    Theo mình tìm hiểu thì:

    DAO (hoặc ADO) là 1 thể thức kết nối SQL với Access trong đó khai báo các giá trị chỉ đích danh cơ sở dữ liệu (như địa chỉ server, tên database, tên người dùng, và mật khẩu). Tuy nhiên, các câu lệnh truy xuất sẽ phải viết dưới dạng class (module) cho từng form. Như vậy sẽ rất rất mất thời gian khi cơ sở dữ liệu có từ 40-50 bảng, liệu phương pháp này thực tế có đang được thực hiện không? 

    Mình cũng đang tìm 1 bản demo cách thức này trên diễn đàn (có backend SQL, frontend Access, kết nối ADO, và vài câu lệnh code viết vào module đơn giản như truy xuất dữ liệu) nhưng không tìm thấy, bạn có thể giúp mình không?

    (26-07-16, 05:33 PM)maidinhdan Đã viết: Không cần thiết đến nổi phải dùng đến MDB, chỉ cần đặt pass có độ dài hợp lý và ký tự đặt biệt là không có một phần nào nảo bẻ khó@ để xem cái code của bạn được đâu.

    Mình hiểu ý bạn nói là "Không cần thiết phải dùng đến MDE" (- chứ không phải MDB) phải không? Còn việc đặt mật khẩu thì mình cũng có nghiên cứu như kiểu 12 ký tự, đè shift nhấn ngày sinh (2607 --> @^)&) và in hoa. Tuy nhiên mật khẩu chỉ giải quyết được vấn đề về hạn chế tiếp cận VBA thôi, còn khả năng hạn chế người dùng xem, sửa, thậm chí xóa thiết kế (design) của form, querries, hay báo cáo thì đâu làm được? (hay mình đang hiểu sai ý bạn?).

    (26-07-16, 05:33 PM)maidinhdan Đã viết: 2 ý trên có cùng nội dung nên minh để chung để trả lời.

    Xem ý số 1 mình viết và bổ sung thêm là dùng thuật toán mã hóa các cột của table khi kết nối bằng Link table mà không phải là ADO hoặc DAO.

    Cái này thì mình chịu rồi, vừa search lại trong diễn đàn từ khóa "mã hóa cột" mà không thấy. Maidinhdan có thế "khai sáng" hơn giúp mình được không?

    Theo mình hiểu ý của bạn là có 1 phương pháp (mã hóa cột) giúp hạn chế người dùng xem, chọn, và copy dữ liệu từ các linked tables phải không? Nếu thế thì quá tuyệt, bạn hướng dẫn giúp mình nhé.
  • RE: Hiểu đúng về phân quyền - MDE - SQL Backend

    hoanbhxhls > 27-07-16, 03:49 PM

    (27-07-16, 09:48 AM)ckno1no Đã viết: Maidinhdan ơi, 

    Trước tiên cám ơn bạn vì đã nhiệt tình "tung tăng" cùng,

    Kế tiếp là, mình chỉ mới đọc và tìm hiểu trên diễn đàn để rút ra nhận định nên thấy bản thân vẫn còn yếu chuyên môn lắm. 

    Theo mình tìm hiểu thì:

    DAO (hoặc ADO) là 1 thể thức kết nối SQL với Access trong đó khai báo các giá trị chỉ đích danh cơ sở dữ liệu (như địa chỉ server, tên database, tên người dùng, và mật khẩu). Tuy nhiên, các câu lệnh truy xuất sẽ phải viết dưới dạng class (module) cho từng form. Như vậy sẽ rất rất mất thời gian khi cơ sở dữ liệu có từ 40-50 bảng, liệu phương pháp này thực tế có đang được thực hiện không? 

    Mình cũng đang tìm 1 bản demo cách thức này trên diễn đàn (có backend SQL, frontend Access, kết nối ADO, và vài câu lệnh code viết vào module đơn giản như truy xuất dữ liệu) nhưng không tìm thấy, bạn có thể giúp mình không?

    (26-07-16, 05:33 PM)maidinhdan Đã viết: Không cần thiết đến nổi phải dùng đến MDB, chỉ cần đặt pass có độ dài hợp lý và ký tự đặt biệt là không có một phần nào nảo bẻ khó@ để xem cái code của bạn được đâu.

    Mình hiểu ý bạn nói là "Không cần thiết phải dùng đến MDE" (- chứ không phải MDB) phải không? Còn việc đặt mật khẩu thì mình cũng có nghiên cứu như kiểu 12 ký tự, đè shift nhấn ngày sinh (2607 --> @^)&) và in hoa. Tuy nhiên mật khẩu chỉ giải quyết được vấn đề về hạn chế tiếp cận VBA thôi, còn khả năng hạn chế người dùng xem, sửa, thậm chí xóa thiết kế (design) của form, querries, hay báo cáo thì đâu làm được? (hay mình đang hiểu sai ý bạn?).

    (26-07-16, 05:33 PM)maidinhdan Đã viết: 2 ý trên có cùng nội dung nên minh để chung để trả lời.

    Xem ý số 1 mình viết và bổ sung thêm là dùng thuật toán mã hóa các cột của table khi kết nối bằng Link table mà không phải là ADO hoặc DAO.

    Cái này thì mình chịu rồi, vừa search lại trong diễn đàn từ khóa "mã hóa cột" mà không thấy. Maidinhdan có thế "khai sáng" hơn giúp mình được không?

    Theo mình hiểu ý của bạn là có 1 phương pháp (mã hóa cột) giúp hạn chế người dùng xem, chọn, và copy dữ liệu từ các linked tables phải không? Nếu thế thì quá tuyệt, bạn hướng dẫn giúp mình nhé.
    -Theo mình dùng giải pháp 'mã hóa cột' là không nên,vì khi dữ liệu nhiều lên thì tính an toàn của dữ liệu khi mã hóa và giải mã liệu có được đảm bảo không
    -Giải pháp link table(kể cả mã khi đã mã hóa) người dùng vẫn có thể open table và delete hết dữ liệu trong table đó
    -Với data của bạn chưa đến 100 table thì cũng là csdl nhỏ,việc viết code truy xuất csdl đều có thể làm được ngay cả khi table trong csdl rất nhiều bằng cách viết các module tổng quát sau đó được gọi ra dùng bằng cách truyền tham số
    -Chính vì vậy việc viết code hoàn toàn làm được cho csdl rất rất nhiều table mà không cần dùng link table
  • RE: Hiểu đúng về phân quyền - MDE - SQL Backend

    maidinhdan > 28-07-16, 05:16 PM

    (27-07-16, 09:48 AM)ckno1no Đã viết: Mình hiểu ý bạn nói là "Không cần thiết phải dùng đến MDE" (- chứ không phải MDB) phải không?

    * Đúng là mình gõ sai từ MDB ( đúng là MDE như bạn nói),

    (27-07-16, 09:48 AM)ckno1no Đã viết: Tuy nhiên mật khẩu chỉ giải quyết được vấn đề về hạn chế tiếp cận VBA thôi, còn khả năng hạn chế người dùng xem, sửa, thậm chí xóa thiết kế (design) của form, querries, hay báo cáo thì đâu làm được? (hay mình đang hiểu sai ý bạn?).

    * Ở phía trên đúng là mình trả lời chưa rõ ràng, xin được bổ sung như thế này.
    Như bạn nói "hạn chế tiếp cận VBA thôi" còn câu sau thì có giải pháp hạn chế người dùng xem, sửa, thậm chí xóa thiết kế (design)
    = > Tùy vào từng phiên bản Access ta sẽ viết code để người dùng không tiếp cận được, cụ thể gồm.

    * Code khóa phím Shift
    * Code khóa thanh Nagative
    * Khóa phím phải chuột từng form
    * Code ẩn khung giao diện

    + Riêng cái vụ Query chuyển lên hết VBA bằng cấu trúc SQL
    + Riêng cái table thì đặt pass cho nó

    Trích dẫn:Cái này thì mình chịu rồi, vừa search lại trong diễn đàn từ khóa "mã hóa cột" mà không thấy. Maidinhdan có thế "khai sáng" hơn giúp mình được không?

    Theo mình hiểu ý của bạn là có 1 phương pháp (mã hóa cột) giúp hạn chế người dùng xem, chọn, và copy dữ liệu từ các linked tables phải không? Nếu thế thì quá tuyệt, bạn hướng dẫn giúp mình nhé.

    Đúng như vậy, bài viết nhiều quá, không biết nó tên gì nửa.

    Tạm thời xem cái link này trước đi: http://thuthuataccess.com/forum/thread-1258.html

    Tìm thấy rồi nè:
    [Hình: Mahoagiaima.png]

    Dựa vào code này, ta sẽ mã hóa ở khâu nhập liệu, khi nào cần đọc thì dùng hàm giải mã.

    Và còn 1 thuật toán nửa đó là "Mã hóa nguyên cái table", nếu bạn cần mình sẽ giới thiệu