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à
Bảo mật code VBA (7 người xem)
- Thread starter myGPE
- Ngày gửi
Người dùng đang xem chủ đề này
Kiều Mạnh
I don't program, I beat code into submission!!!
- Tham gia
- 9/6/12
- Bài viết
- 5,538
- Được thích
- 4,132
- Giới tính
- Nam
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;
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;
Upvote
0
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ả.
Upvote
0
ongke0711
Thành viên gắn bó
- Tham gia
- 7/9/06
- Bài viết
- 2,288
- Được thích
- 3,077
- Giới tính
- Nam
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).
Upvote
0
huuthang_bd
Chuyên gia GPE
- Tham gia
- 10/9/08
- Bài viết
- 8,928
- Được thích
- 11,334
- Donate (Momo)
- Giới tính
- Nam
- Nghề nghiệp
- Thợ đụng
Đâu có file mã hóa đâu bạn, tôi đề xuất lưu thông tin trên Registry mà.
Upvote
0
ongke0711
Thành viên gắn bó
- Tham gia
- 7/9/06
- Bài viết
- 2,288
- Được thích
- 3,077
- Giới tính
- Nam
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.
Lần chỉnh sửa cuối:
Upvote
0
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.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).
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.
Upvote
0
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.
Upvote
0
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.
Upvote
0
huuthang_bd
Chuyên gia GPE
- Tham gia
- 10/9/08
- Bài viết
- 8,928
- Được thích
- 11,334
- Donate (Momo)
- Giới tính
- Nam
- Nghề nghiệp
- Thợ đụng
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.
@ongke0711 Theo tôi hiểu là thớt muốn giấu ServerName và DatabaseName để nếu chẳng may Username và Password bị lộ mà ServerName và DatabaseName vẫn được bảo mật thì hệ thống vẫn an toàn.
Do đó tôi đề xuất mã hóa ServerName và DatabaseName sau đó lưu chuỗi mã hóa vào Registry. Khi code thực thi sẽ đọc chuỗi mã hóa này và giải mã lấy ServerName và DatabaseName.
Với cách làm trên nếu file excel bị rò rỉ và bị bẻ khóa thì 'kẻ gian' cũng không lấy được ServerName và DatabaseName do Registry không có chuỗi mã hóa. Người dùng bình thường thì sẽ không thấy được ServerName và DatabaseName do thông tin lưu vào Registry đã bị mã hóa.
Giải pháp này chỉ để giảm thiểu rủi ro khi file bị lọt ra ngoài, nếu người trong công ty được phân quyền truy cập server để làm việc mà muốn phá thì khó mà đỡ được.
Upvote
0
ongke0711
Thành viên gắn bó
- Tham gia
- 7/9/06
- Bài viết
- 2,288
- Được thích
- 3,077
- Giới tính
- Nam
Chính xác là vậy. Do đó tôi mới nói thêm là trường hợp người nội bộ có ý gian và có thể ngồi vào những máy có lưu thông tin trong registry. Tôi nghĩ các lưu luôn vào dll thì an toàn hơn. Mỗi khi có thay đổi thông tin server thì gửi file dll để cập nhật.
À mà cách này cũng không an toàn…
Lần chỉnh sửa cuối:
Upvote
0
Công ty này chắc chắn là bung gốc, rễ, lẫn cành lá rồi.
Kiểu bảo mật code thế này là làm áp lực với chủ. Thớt mà nổi giận bỏ đi thì công ty mất một đống files và dữ liệu.
Upvote
0
Bài viết mới nhất
- Question
