Bảo mật code VBA

[n.n.Tien]

Mình có 1 file *.xslm có chứa code VBA và muốn bảo mật code VBA để người khác ko chỉnh sửa được. Mặc dù đã đặt mật mã cho đoạn code nhưng vẫn bị bẻ khóa. Nhờ các ace trong Group có biện pháp nào giúp mình bảo mật được code VBA khi mình chia sẻ file cho người khác dùng chung đc ko nhỉ? Thanks cả nhà

 

[Kiều Mạnh]

Lưu Password vào đâu đó thì tuỳ theo sở thích VD: Registry hay Fields của Data.accdb
nhưng khi lưu Password đó đã mã hoá = tuỳ thích kiểu mã hoá ... phòng khi có thấy cũng chỉ nhìn

xong viết hàm so sánh mã hoá đó có thể sử dụng SHA256 hiện tại tạm an toàn .. trong Delphi tôi sử dụng hàm sau so sánh Password

function ValidatePasswordSHA256(const Password, HashedPassword: string) : Boolean;

 

[ongke0711]

Lưu Password vào đâu đó thì tuỳ theo sở thích VD: Registry hay Fields của Data.accdb

Lưu địa chỉ Server và Database name chứ không phải password nhé. Người dùng không thể nào nhớ tham số này để mà gõ vô, để rồi so sánh với chuỗi mã hóa nhé. Xử lý password thì đã nói ở trên rồi.

 

[cantl]

Có 1 cách là tung code lên, đặt mấy cái cần cất là xxx, yyy, zzz. Rồi nhờ nếu bí hoặc xin kỹ thuật giấu nếu biết.

 

[ongke0711]

Có một kỹ thuật khác là làm rối code (Obfuscalator) để nhìn vô code cũng khônbg biết sửa sao . Phải lưu file gốc chứ không là tèo luôn.

 

[Kiều Mạnh]

Lưu địa chỉ Server và Database name chứ không phải password nhé. Người dùng không thể nào nhớ tham số này để mà gõ vô, để rồi so sánh với chuỗi mã hóa nhé. Xử lý password thì đã nói ở trên rồi.

thì viết lại hàm thôi .. đơn giản thôi mà
Chọn mã hoá SHA256 + Keys tăng thêm phần bảo mật

 

[ongke0711]

thì viết lại hàm thôi .. đơn giản thôi mà
Chọn mã hoá SHA256 + Keys tăng thêm phần bảo mật

Đọc thật kỹ đề bài nhé.

 

[gttrongvn]

Cảm ơn bạn đã nhắc nhở. Code của mình thì cũng ko có gì ghê gớm cả. chỉ phục vụ chuyên môn công việc riêng thôi. Nhưng có điều quan trọng là trong file của mình sử dụng liên kết đến SQL Server của công ty. Nếu như bị bẻ khóa thì đồng nghĩa với việc bị lộ Server name, User, Pw. Đấy là điều tôi lo ngại nhất chứ tôi cũng ko tiếc gì mà ngại ngần chia sẻ cho các đồng nghiệp!
Bạn có cách nào mà khi bị bẻ khóa vẫn bảo vệ đc Server, User & Pw ko?
Bạn là thành viên của nơi đã cho bạn công ăn việc làm thì bạn có muốn để những việc gây hại cho tổ chức của mình ko???
Nếu là ích kỷ thì chỉ dành riêng cho bản thân mình dùng, chứ còn mang đi chia sẻ cho người khác dùng làm chi. Nếu như bạn làm ra 1 thứ hoặc ít nhất là cũng mất bao công sức tìm kiếm học hỏi để làm ra cho người khác sử dụng free rồi sau đó là mất dữ liệu, lộ thông tin..... Theo bạn cái đó có cần đc bảo vệ ko???

Mình đang xây dựng dự án cho công ty theo hướng của bạn, code vba và file excel thì mình không bảo mật gì cả, các bạn trong công ty nếu cần có thể tham khảo, mình chỉ bảo mật dữ liệu của công ty thôi. Cách bảo mật của mình là tạo User trên sql server chỉ có duy nhất quyền thực thi "execute" các stored procedure (Bạn tìm hiểu từ khóa "GRANT EXECUTE ON OBJECT::dbo.<Stored Procedure> to <User>). Người dùng (bình thường) nếu có biết thông tin server thì cũng không thể làm được gì nhiều cả.

 

[ongke0711]

Cách bảo mật của mình là tạo User trên sql server chỉ có duy nhất quyền thực thi "execute" các stored procedure (Bạn tìm hiểu từ khóa "GRANT EXECUTE ON OBJECT::dbo.<Stored Procedure> to <User>). Người dùng (bình thường) nếu có biết thông tin server thì cũng không thể làm được gì nhiều cả.

Thực ra như bài trước của tôi là chỉ cần dấu User/Pass kết nối tới SQL SV là đủ rồi. Nhưng chủ thớt còn muốn dấu luôn địa chỉ server và Database đề phòng lộ User/pass thì cũng không biết đường mà kết nối tới máy chủ nên mới vẽ ra thêm Dll, obfuscator các kiểu... .
Theo như cách của bạn, nếu lộ User/pass thì kết nối vô chạy stored procedure DELETE, SELECT là mệt rồi (Tên SP lưu trong code VBA).

 

[huuthang_bd]

Nếu họ có file thì có code giải mã trong đó + file mã hóa thì học cũng giải được đúng không bạn? hay có cách mã hóa khác mà tôi chưa hình dung ra.

Đâu có file mã hóa đâu bạn, tôi đề xuất lưu thông tin trên Registry mà.

 

[ongke0711]

Đâu có file mã hóa đâu bạn, tôi đề xuất lưu thông tin trên Registry mà.

Tôi có đọc cái đề xuất này của bạn đó chứ nhưng bạn cũng có nói nếu người trong cty cố tình xâm nhập thì cũng không còn an toàn nữa. Họ lên chính cái máy đó trích xuất thông tin từ Registry.
Nói chung tôi thấy kiểu gì cũng chỉ an toàn tương đối, chắc phải dùng cái USB token đem theo bên người, cứ 30s thì đổi key 1 lần... .
Bạn nói rõ thêm cách này nếu tôi hiểu sai.
Tôi thì chỉ dùng 2 tầng mật khẩu là MK đăng nhập SQL SV và mật khẩu đăng nhập vào ứng dụng là đủ đối với tôi rồi. Còn mà mất mật khẩu thì lo mà reset lại ngay.

 

[gttrongvn]

Thực ra như bài trước của tôi là chỉ cần dấu User/Pass kết nối tới SQL SV là đủ rồi. Nhưng chủ thớt còn muốn dấu luôn địa chỉ server và Database đề phòng lộ User/pass thì cũng không biết đường mà kết nối tới máy chủ nên mới vẽ ra thêm Dll, obfuscator các kiểu... .
Theo như cách của bạn, nếu lộ User/pass thì kết nối vô chạy stored procedure DELETE, SELECT là mệt rồi (Tên SP lưu trong code VBA).

Mình đang nói tới nhóm người dùng bình thường, bạn đang đề cập tới là người dùng có kiến thức IT nhưng có ý định phá rồi, nó lại nằm ở phần bảo mật của System Admin và Database Admin. Theo mình nghĩ nếu bạn có user/pass để đăng nhập 1 trang web và có API để thực thi các hàm liên quan xem, xóa, sửa thì cũng như vấn đề bạn nói lộ thông tin câu sp ở VBA thôi.
Cho trường hợp phá hoại như bạn nói, hướng mình đang xử lý:
Câu lệnh DELETE/UPDATE: Người dùng có quyền liên quan mới có thể thực thi 2 lệnh này, mình luôn để where tối thiểu với 2 điều kiện mới được thực thi, 2 điều kiện ấy tạo ra 1 unique key trong bảng đó.
Câu lệnh SELECT: nếu người dùng cố tình làm để chiếm dụng ram hay cpu thì có cách dò ra ip và block ip đó.
Nói chung là có nhiều cách để phá hoại và phòng chống lắm. Phương án cuối cùng của mình là backup database theo cơ chế Full-Differential-TransactionLog, mỗi 15 phút sẽ sao lưu 1 lần, bản sao lưu sẽ được backup qua Cloud thêm lần nữa. Nên khi server dính ransomeware đi nữa thì dữ liệu đã được sao lưu và không ảnh hưởng tới vận hành của công ty nhiều.

 

[VetMini]

Mình đang nói tới nhóm người dùng bình thường, bạn đang đề cập tới là người dùng có kiến thức IT nhưng có ý định phá rồi, nó lại nằm ở phần bảo mật của System Admin và Database Admin. Theo mình nghĩ nếu bạn có user/pass để đăng nhập 1 trang web và có API để thực thi các hàm liên quan xem, xóa, sửa thì cũng như vấn đề bạn nói lộ thông tin câu sp ở VBA thôi.
Cho trường hợp phá hoại như bạn nói, hướng mình đang xử lý:
Câu lệnh DELETE/UPDATE: Người dùng có quyền liên quan mới có thể thực thi 2 lệnh này, mình luôn để where tối thiểu với 2 điều kiện mới được thực thi, 2 điều kiện ấy tạo ra 1 unique key trong bảng đó.
Câu lệnh SELECT: nếu người dùng cố tình làm để chiếm dụng ram hay cpu thì có cách dò ra ip và block ip đó.
Nói chung là có nhiều cách để phá hoại và phòng chống lắm. Phương án cuối cùng của mình là backup database theo cơ chế Full-Differential-TransactionLog, mỗi 15 phút sẽ sao lưu 1 lần, bản sao lưu sẽ được backup qua Cloud thêm lần nữa. Nên khi server dính ransomeware đi nữa thì dữ liệu đã được sao lưu và không ảnh hưởng tới vận hành của công ty nhiều.

Lệnh DROP TABLE thì sao bạn?
Admin sợ nhất là người dùng để lổ hổng khiến kẻ phá hoại có thể dùng SQL injection.
Nếu dùng stored procedure (sp) thì sẽ vô hiệu hóa SQL Injection.
Admin chỉ việc kiểm soát quyền kết nối và chạy sp thôi.

Server không đủ mạnh mà chạy Differential Transaction log thì sẽ mửa mật. Phải cỡ một array máy, một chùm Ram, thúng đĩa. Bi giờ là đĩa SSD cũng đỡ, nhớ đên khoảng năm 1990 thúng đĩa này lớn như mấy cái lu nước sắp hàng, sau đó thì thâu lại còn cỡ cái tủ nhỏ. Đĩa SSD thì chỉ như một ram giấy.

 

[gttrongvn]

Lệnh DROP TABLE thì sao bạn?
Admin sợ nhất là người dùng để lổ hổng khiến kẻ phá hoại có thể dùng SQL injection.
Nếu dùng stored procedure (sp) thì sẽ vô hiệu hóa SQL Injection.
Admin chỉ việc kiểm soát quyền kết nối và chạy sp thôi.

Server không đủ mạnh mà chạy Differential Transaction log thì sẽ mửa mật. Phải cỡ một array máy, một chùm Ram, thúng đĩa. Bi giờ là đĩa SSD cũng đỡ, nhớ đên khoảng năm 1990 thúng đĩa này lớn như mấy cái lu nước sắp hàng, sau đó thì thâu lại còn cỡ cái tủ nhỏ. Đĩa SSD thì chỉ như một ram giấy.

Em phân quyền User chỉ duy nhất quyền thực thi "EXECUTE" câu SP đó thì user sẽ không thực thi "DROP" được thầy kể cả xem Table hay View, phải phân quyền user mới sử dụng được. Server công ty bên em đang sử dụng cho hiện tại 8core 16gb ram, xài cơ chế backup này mấy năm nay bình thường mà. Công ty em hoạt động vào giờ hành chỉnh là chủ yếu, Full thì em backup hàng tuần 1 lần lúc 12h khuya, thời điểm công ty không hoạt động, Differential thì mỗi ngày backup 1 lần cũng 12h khuya, còn Transaction thì mỗi 15p 1 lần, nó không chiếm dụng tài nguyên SQL server bao nhiêu hết thầy. Cơ chế backup cũng tùy thuộc vào mô hình hoạt động/độ lớn của công ty để canh giờ sao lưu cho hợp lý nữa, nếu công ty hoạt động 24/7 thì sẽ có cơ chế backup khác nữa thầy.