Giải pháp bạn đưa ra khá flexible , nhưng bạn lại chưa hiểu vấn đề chính mà tôi muốn đưa ra. Thay đổi user_auth chỉ là 1 ví dụ nhỏ, như bạn đã nêu, tính toàn vẹn phải được giữ để nếu có bị thay đổi username hoặc password thì cũng không thể chiếm được tài khoản cấp cao.

Ví dụ như tôi thấy forum hva có tài khoản tên là quanlytruong. Nếu ngày nào đó MySQL bị lỗi có thể bị khai thác. Với cấu trúc database của JForum thì hoàn toàn có thể chiến tài khoản cấp cao đó để phá hoại forum. Vậy người modify JFroum cho HVA có đảm bảo được tính toàn vẹn đó không? 

Tôi đang bàn đến cái khó về cơ sở hạ tầng, không phải ai cũng có server, VPS riêng nên mới bị local attack. Hoặc nếu có server riêng, nhưng có thể bị sơ hở ở chỗ nào khác trên server như: 1 server có nhiều site, site X nào đó bị lỗ hổng...
 

Chào mọi người.

Mình đang tập làm 1 module bảo mật cho dữ liệu chứa trong MySQL và chạy bằng PHP.

Dữ liệu:
1) Có bảng chứa tài khoản người dùng: USERS bao gồm: user_id, user_name, user_pass, user_auth...
2) Bảng AUTH chứ danh sách cấp bậc của USERS: auth_id, auth_type, user_id,....

Vấn đề đặt ra là:
1) Có người xâm nhập vào MySQL như bị local attack
2) Người này sửa user_auth của user nào đó thành 1, tức thành Quản trị

Giải pháp nào cho:
1) Có thể bị mất database, bị sửa MySQL trái phép từ ngoài.
2) Tuy nhiên, nếu sửa lại user_auth thành Quản trị thì cũng không được gì.

Ở trường hợp này, tính toàn vẹn của dữ liệu trong bảng đã không hợp lệ. Vậy có giải pháp nào để đảm bảo tính toán vẹn đó?

Thân chào. 

----> khắc phục cái rễ, đừng khắc phục cái ngọn. Khắc phục bảo mật cho 1 và 2. 

conmale wrote:

----> khắc phục cái rễ, đừng khắc phục cái ngọn. Khắc phục bảo mật cho 1 và 2. 

Em tưởng bác nói ngọng, khắc phục cái dễ...
Bác nên nói là: "khắc phục cái gốc, đừng khắc phục cái ngọn".

Ôi tiếng Việt. 

Mình đoán rằng mong muốn của bạn là bạn bị cướp quyền admin của MySQL, nhưng các file code không bị làm sao (có thể bị xem nhưng không thể thay đổi).
Và bạn muốn đảm bảo rằng DB của bạn phải toàn vẹn, mới cho phép truy cập.
Cái này nói chung là không quá khó, nhưng sẽ tốn thêm công và tất nhiên hệ thống sẽ chậm đi. Ví dụ bạn có thể áp dụng chữ ký điện tử vào DB, có thêm 1 cột chứa digital signature của các field còn lại. Trong code có mã kiểm tra chữ ký + public key để check có hợp lệ hay không, để biết bản ghi đó có bị thay đổi hay ko hợp lệ...
Việc tạo chữ ký thì là offline, private key bạn giữ tại client, mỗi khi có update row thì phải thực hiện việc ký lại các field đó tại client và update lại cột chữ ký.
Như vậy, nếu có ai đó thay đổi dữ liệu, chữ ký ko match thì ko còn vào được nữa. Tất nhiên code không bị thay đổi nên attacker không thể bypass việc check đó.
Việc này chỉ chống được có thế, chứ nếu attacker drop luôn các bảng của bạn, hệ thống ko xài được nữa, thì ... nói chung hậu quả có thể vẫn đáng kể.
Cách này người ta thường áp dụng cho 1 số giao dịch tài chính ngân hàng, để đảm bảo toàn vẹn của dữ liệu giao dịch sinh ra trong hệ thống (nghĩa là hacker không thể sinh ra giao dịch giả mạo, tác giả sinh GD là ai thì sẽ có chữ ký tương ứng xác nhận) 

----> khắc phục cái rễ, đừng khắc phục cái ngọn. Khắc phục bảo mật cho 1 và 2. 

conmale wrote:

----> khắc phục cái rễ, đừng khắc phục cái ngọn. Khắc phục bảo mật cho 1 và 2. 

Trả lời kiểu đánh đố này thì chẳng khác nào khi muốn quan hệ tình dục với phụ nữ nào đó thì nên check rồi xử virus HIV có trong máu chứ dùng BCS thì có mà bị lòi rễ Bác này chắc chưa hiểu đạo lý sống: "Sống chung với lũ" là như thế nào hoặc như người Nhật: "Sống chung với động đất" 

beta14 wrote:

conmale wrote:

----> khắc phục cái rễ, đừng khắc phục cái ngọn. Khắc phục bảo mật cho 1 và 2. 

Trả lời kiểu đánh đố này thì chẳng khác nào khi muốn quan hệ tình dục với phụ nữ nào đó thì nên check rồi xử virus HIV có trong máu chứ dùng BCS thì có mà bị lòi rễ Bác này chắc chưa hiểu đạo lý sống: "Sống chung với lũ" là như thế nào hoặc như người Nhật: "Sống chung với động đất" 

Tôi chẳng đánh đố, tôi chẳng trả lời mà tôi chỉ khuyên bạn. Việc bạn so sánh điều tôi khuyên bạn với chuyện quan hệ tình dục hay đạo lý 'sống chung với lũ' gì gì đó hoàn toàn lạc đề.

Bạn đưa ra vấn đề như thể làm thế nào để đừng cho thằng ăn trộm chôm đồ của mình sau khi nó đã vào được trong nhà và cầm trong tay một chùm chìa khóa có thể mở tất cả các tủ vậy. Đây là chuyện buồn cười. Bạn nên nghĩ đến chuyện làm sao không cho thằng ăn trộm vào nhà chớ đừng nghĩ đến chuyện nó đã vào nhà rồi thì làm gì. 

conmale wrote:

beta14 wrote:

conmale wrote:

----> khắc phục cái rễ, đừng khắc phục cái ngọn. Khắc phục bảo mật cho 1 và 2. 

Trả lời kiểu đánh đố này thì chẳng khác nào khi muốn quan hệ tình dục với phụ nữ nào đó thì nên check rồi xử virus HIV có trong máu chứ dùng BCS thì có mà bị lòi rễ Bác này chắc chưa hiểu đạo lý sống: "Sống chung với lũ" là như thế nào hoặc như người Nhật: "Sống chung với động đất" 

Tôi chẳng đánh đố, tôi chẳng trả lời mà tôi chỉ khuyên bạn. Việc bạn so sánh điều tôi khuyên bạn với chuyện quan hệ tình dục hay đạo lý 'sống chung với lũ' gì gì đó hoàn toàn lạc đề.

Bạn đưa ra vấn đề như thể làm thế nào để đừng cho thằng ăn trộm chôm đồ của mình sau khi nó đã vào được trong nhà và cầm trong tay một chùm chìa khóa có thể mở tất cả các tủ vậy. Đây là chuyện buồn cười. Bạn nên nghĩ đến chuyện làm sao không cho thằng ăn trộm vào nhà chớ đừng nghĩ đến chuyện nó đã vào nhà rồi thì làm gì. 

Có lẽ bạn đang tạo ra một chuỗi truyện cười, hay do bạn cố tình không hiểu? Hơn 95% các doanh nghiệp là nhỏ và vừa, cũng gần bằng đó số người dân phải sống nhà thuê chứ không phải nhà riêng của họ, ngay cả khi bạn dẫn gái vào thuê phòng trong khách sạn thì căn phòng đó cũng chưa hẳn đã là của riêng bạn để giữ kín dữ liệu nhảy cảm của mình. Không biết với những ví dụ như vậy thì bạn có hình dung được cái case mà tôi muốn bàn đến? 

1) Có bảng chứa tài khoản người dùng: USERS bao gồm: user_id, user_name, user_pass, user_auth...
2) Bảng AUTH chứ danh sách cấp bậc của USERS: auth_id, auth_type, user_id,....

Vấn đề đặt ra là:
1) Có người xâm nhập vào MySQL như bị local attack
2) Người này sửa user_auth của user nào đó thành 1, tức thành Quản trị

Giải pháp nào cho:
1) Có thể bị mất database, bị sửa MySQL trái phép từ ngoài.
2) Tuy nhiên, nếu sửa lại user_auth thành Quản trị thì cũng không được gì.  

Ah không "chú" comale chứ.( Nên tôn trọng và học hỏi kinh nghiệm từ những người "lớn tuổi" )