Mysql tìm kiếm dữ liệu được mã hóa

Chúng tôi đã mã hóa rõ ràng một số Dữ liệu PII tại Cơ sở dữ liệu MySQL của chúng tôi. Điều này đang gây ra một số sự cố trong khi kết nối với Cơ sở dữ liệu của chúng tôi và đưa nó vào nơi khác mà luôn cần giải mã

Có cách nào để chúng tôi có thể tận dụng điều này cho Azure MySQL nơi tôi đọc Mã hóa được sử dụng theo mặc định và trong khi đọc dữ liệu, nó tự động giải mã nội dung và chia sẻ lại cho các truy vấn

Nếu điều này là có thể, chúng tôi có thấy dữ liệu được mã hóa cho các cột đã nói hoặc toàn bộ dữ liệu của Bảng khi xem nó trên Cơ sở dữ liệu không và khi nào nó thực sự trả về phiên bản được giải mã

Bất kỳ đầu vào nào về điều này sẽ thực sự hữu ích

Cảm ơn,
Kotesh

Nhận xét · Hiển thị 2

Bình luận

5. Cần 1600 ký tự còn lại ký tự

▼

tệp đính kèm. Có thể sử dụng tối đa 10 tệp đính kèm (bao gồm cả hình ảnh) với tối đa 3. 0 MiB mỗi cái và 30. tổng cộng 0 MiB

Mike Benshoof2022-09-20T08. 01. 35-04. 00

Tác giả Mike Benshoof Thông tin chi tiết về DBA, MySQL, Phần mềm Percona, Bảo mật mã hóa, MySQL, mysql và các biến thể

Trong một

Kể từ bản phát hành hiện tại của Máy chủ Percona dành cho MySQL, không có cách tích hợp nào để xác định một cột duy nhất là được mã hóa. Lý tưởng nhất là có thể có một số siêu dữ liệu được chuyển trong câu lệnh tạo và điều này sẽ tự động xảy ra, chẳng hạn như điều này

TẠO BẢNG pii_data (

user_id int KHÓA CHÍNH không dấu,

super_secret  varchar(255) ĐƯỢC MÃ HÓA,

…

… ) ĐỘNG CƠ=InnoDB

Rất tiếc, tùy chọn này không khả dụng và chúng tôi cần thực hiện một số thao tác dữ liệu vào hoặc trước thời điểm đọc/ghi

Chức năng mã hóa MySQL tích hợp

Một trong những cách tiếp cận phổ biến nhất là sử dụng các chức năng mã hóa MySQL tích hợp được mô tả tại đây. https. // nhà phát triển. mysql. com/doc/refman/8. 0/vi/hàm mã hóa. html. Các luồng tiêu chuẩn trông giống như thế này.

CHÈN VÀO mytable (id, secret_data)  VALUES (1, TO_BASE64(AES_ENCRYPT(“dữ liệu cực kỳ bí mật”, “khóa của tôi”)));

Câu hỏi này thỉnh thoảng xuất hiện trong. Đây là một trong những “vấn đề kỳ lạ” được đề cập trong bài nói chuyện của tôi tại B-Sides Orlando (có tiêu đề Xây dựng các giải pháp phòng thủ cho các vấn đề kỳ lạ) và trước đây chúng tôi đã dành một phần nhỏ cho vấn đề này trong

Bạn biết cách tìm kiếm các trường trong cơ sở dữ liệu, nhưng câu hỏi đặt ra là Làm cách nào để chúng tôi mã hóa các trường cơ sở dữ liệu một cách an toàn mà vẫn sử dụng các trường này trong các truy vấn tìm kiếm?

Giải pháp an toàn của chúng tôi khá đơn giản, nhưng con đường giữa hầu hết các nhóm đặt câu hỏi đó và khám phá ra giải pháp đơn giản của chúng tôi đầy nguy hiểm. thiết kế tồi, dự án nghiên cứu học thuật, tiếp thị sai lệch và mô hình hóa mối đe dọa kém

Nếu bạn đang vội, cứ tự nhiên

Hướng tới mã hóa có thể tìm kiếm

Hãy bắt đầu với một kịch bản đơn giản (có thể đặc biệt phù hợp với nhiều ứng dụng chăm sóc sức khỏe hoặc chính quyền địa phương)

• Bạn đang xây dựng một hệ thống mới cần thu thập số an sinh xã hội (SSN) từ người dùng của nó
• Các quy định và lẽ thường đều quy định rằng SSN của người dùng phải được mã hóa khi lưu trữ
• Nhân viên sẽ cần có khả năng tra cứu tài khoản của người dùng, được cung cấp SSN của họ

Trước tiên hãy khám phá những sai sót với câu trả lời rõ ràng cho vấn đề này

Câu trả lời không an toàn (hoặc nói cách khác là không nên)

Mã hóa không ngẫu nhiên

Câu trả lời rõ ràng nhất đối với hầu hết các nhóm (đặc biệt là các nhóm không có chuyên gia về bảo mật hoặc mật mã) sẽ làm một việc như thế này

class InsecureExampleOne
{
    protected $db;
    protected $key;

    public function __construct(\PDO $db, string $key = '')
    {
        $this->db = $db;
        $this->key = $key;
    }

    public function searchByValue(string $query): array
    {
        $stmt = $this->db->prepare('SELECT * FROM table WHERE column = ?');
        $stmt->execute([
            $this->insecureEncryptDoNotUse($query)
        ]);
        return $stmt->fetchAll(\PDO::FETCH_ASSOC);
    }

    protected function insecureEncryptDoNotUse(string $plaintext): string
    {
        return \bin2hex(
            \openssl_encrypt(
                $plaintext,
                'aes-128-ecb',
                $this->key,
                OPENSSL_RAW_DATA | OPENSSL_ZERO_PADDING
            )
        );
    }
}

Trong đoạn mã trên, cùng một bản rõ luôn tạo ra cùng một bản mã khi được mã hóa bằng cùng một khóa. Nhưng điều đáng lo ngại hơn với chế độ ECB là mỗi đoạn 16 byte được mã hóa riêng, điều này có thể gây ra một số hậu quả cực kỳ đáng tiếc

Về mặt hình thức, các cấu trúc này không an toàn về mặt ngữ nghĩa. Nếu bạn mã hóa một tin nhắn lớn, bạn sẽ thấy các khối lặp lại trong bản mã

Để được an toàn, mã hóa phải không thể phân biệt được với nhiễu ngẫu nhiên với bất kỳ ai không giữ khóa giải mã. Các chế độ không an toàn bao gồm chế độ ECB và chế độ CBC với IV tĩnh (hoặc trống)

Bạn muốn mã hóa không xác định, có nghĩa là mỗi thông báo sử dụng một vectơ khởi tạo hoặc nonce duy nhất không bao giờ lặp lại cho một khóa nhất định

Thiết kế học thuật thử nghiệm

Có rất nhiều nghiên cứu học thuật đi sâu vào các chủ đề như kỹ thuật mã hóa đồng cấu, tiết lộ thứ tự và bảo toàn thứ tự

Thú vị như công việc này, các thiết kế hiện tại không đủ an toàn để sử dụng trong môi trường sản xuất

Ví dụ: mã hóa tiết lộ thứ tự làm rò rỉ đủ dữ liệu để suy ra văn bản gốc

Các sơ đồ mã hóa đồng hình thường đóng gói lại các lỗ hổng (các cuộc tấn công bằng bản mã được chọn thực tế) dưới dạng các tính năng

• RSA không đệm là đồng hình đối với phép nhân
  • Nếu bạn nhân một bản mã với một số nguyên, thì bản rõ bạn nhận được sẽ bằng thông điệp ban đầu nhân với cùng một số nguyên. Có một số cuộc tấn công có thể xảy ra đối với RSA không đệm, đó là lý do tại sao RSA trong thế giới thực sử dụng đệm (mặc dù thường là chế độ đệm không an toàn)
• AES trong Chế độ truy cập đồng hình đối với XOR
  • Đây là lý do tại sao việc không sử dụng lại làm mất tính bảo mật của tin nhắn của bạn ở chế độ CTR (và nói chung là mật mã luồng không phải NMR)

Như chúng ta đã đề cập trong một bài đăng trên blog trước đây, khi nói đến mật mã trong thế giới thực, tính bảo mật mà không có tính toàn vẹn cũng giống như không có tính bảo mật. Điều gì xảy ra nếu kẻ tấn công giành được quyền truy cập vào cơ sở dữ liệu, thay đổi bản mã và nghiên cứu hành vi của ứng dụng khi giải mã?

Có tiềm năng cho việc nghiên cứu mật mã đang diễn ra để một ngày nào đó tạo ra một thiết kế mã hóa sáng tạo không làm mất đi hàng thập kỷ nghiên cứu về các nguyên mẫu mật mã an toàn và thiết kế giao thức mật mã. Tuy nhiên, chúng tôi vẫn chưa đạt được điều đó và bạn không cần phải đầu tư vào một nguyên mẫu nghiên cứu phức tạp không cần thiết để giải quyết vấn đề

Đề cập đến không trung thực. Giải mã mỗi hàng

Tôi không mong đợi hầu hết các kỹ sư đi đến giải pháp này mà không có một chút mỉa mai nào. Ý tưởng tồi ở đây là, bởi vì bạn cần mã hóa an toàn (xem bên dưới), cách duy nhất của bạn là truy vấn mọi bản mã trong cơ sở dữ liệu và sau đó lặp lại chúng, giải mã từng cái một và thực hiện thao tác tìm kiếm của bạn trong mã ứng dụng

Nếu bạn đi theo con đường này, bạn sẽ mở ứng dụng của mình trước các cuộc tấn công từ chối dịch vụ. Nó sẽ chậm đối với người dùng hợp pháp của bạn. Đây là câu trả lời của một người hoài nghi và bạn có thể làm tốt hơn thế nhiều, như chúng tôi sẽ chứng minh bên dưới

Mã hóa có thể tìm kiếm an toàn được thực hiện dễ dàng

Hãy bắt đầu bằng cách tránh tất cả các vấn đề được nêu trong phần không an toàn/không nên làm ngay lập tức. Tất cả các bản mã sẽ là kết quả của một sơ đồ mã hóa được xác thực, tốt nhất là với các nonce lớn (được tạo từ một trình tạo số ngẫu nhiên an toàn)

Với sơ đồ mã hóa được xác thực, các bản mã là không xác định (cùng một thông báo và khóa, nhưng nonce khác nhau, tạo ra một bản mã khác) và được bảo vệ bởi thẻ xác thực. Một số tùy chọn phù hợp bao gồm. XSalsa20-Poly1305, XChacha20-Poly1305 và (giả sử nó không bị hỏng trước khi CAESAR kết thúc) NORX64-4-1. Nếu bạn đang sử dụng NaCl hoặc libsodium, bạn chỉ có thể sử dụng crypto_secretbox tại đây

Do đó, các bản mã của chúng tôi không thể phân biệt được với nhiễu ngẫu nhiên và được bảo vệ trước các cuộc tấn công bằng bản mã đã chọn. Đó là cách mã hóa an toàn, nhàm chán

Tuy nhiên, điều này đặt ra một thách thức trước mắt. Chúng tôi không thể chỉ mã hóa các tin nhắn tùy ý và truy vấn cơ sở dữ liệu để tìm các bản mã phù hợp. May mắn thay, có một cách giải quyết thông minh

Quan trọng. Mô hình mối đe dọa Cách sử dụng mã hóa của bạn

Trước khi bạn bắt đầu, hãy đảm bảo rằng mã hóa thực sự giúp dữ liệu của bạn an toàn hơn. Điều quan trọng cần nhấn mạnh là “bộ nhớ được mã hóa” không phải là giải pháp để bảo mật ứng dụng CRUD dễ bị tấn công SQL injection. Giải quyết vấn đề thực tế (i. e. ngăn chặn việc tiêm SQL) là cách duy nhất để thực hiện

Nếu mã hóa là biện pháp kiểm soát bảo mật phù hợp để triển khai, điều này có nghĩa là phần mềm cơ sở dữ liệu không thể truy cập các khóa mật mã được sử dụng để mã hóa/giải mã dữ liệu. Trong hầu hết các trường hợp, nên giữ máy chủ ứng dụng và máy chủ cơ sở dữ liệu trên phần cứng riêng biệt

Thực hiện tìm kiếm theo nghĩa đen của dữ liệu được mã hóa

Trường hợp sử dụng có thể. Lưu trữ số an sinh xã hội, nhưng vẫn có thể truy vấn chúng

Để lưu trữ thông tin được mã hóa và vẫn sử dụng văn bản gốc trong các truy vấn CHỌN, chúng tôi sẽ thực hiện theo một chiến lược mà chúng tôi gọi là lập chỉ mục mù. Ý tưởng chung là lưu trữ một hàm băm có khóa (e. g. HMAC) của bản rõ trong một cột riêng biệt. Điều quan trọng là khóa chỉ mục mù phải khác với khóa mã hóa và máy chủ cơ sở dữ liệu không xác định được

Đối với thông tin rất nhạy cảm, thay vì HMAC đơn giản, bạn sẽ muốn sử dụng thuật toán kéo dài khóa (PBKDF2-SHA256, scrypt, Argon2) với khóa đóng vai trò là muối tĩnh, để làm chậm nỗ lực liệt kê. Chúng tôi không lo lắng về các cuộc tấn công vũ phu ngoại tuyến trong cả hai trường hợp, trừ khi kẻ tấn công có thể lấy được khóa (không được lưu trữ trong cơ sở dữ liệu)

Vì vậy, nếu lược đồ bảng của bạn trông như thế này (theo hương vị PostgreSQL)

CREATE TABLE humans (

    humanid BIGSERIAL PRIMARY KEY,
    first_name TEXT,
    last_name TEXT,
    ssn TEXT, /* encrypted */
    ssn_bidx TEXT /* blind index */
);
CREATE INDEX ON humans (ssn_bidx);

Bạn sẽ lưu trữ giá trị được mã hóa trong humans.ssn. Một chỉ mục mù của SSN bản rõ sẽ đi vào humans.ssn_bidx. Một triển khai ngây thơ có thể trông như thế này

/* This is not production-quality code.
 * It's optimized for readability and understanding, not security.
 */

function encryptSSN(string $ssn, string $key): string
{
    $nonce = random_bytes(24);
    $ciphertext = sodium_crypto_secretbox($ssn, $nonce, $key);
    return bin2hex($nonce . $ciphertext);
}

function decryptSSN(string $ciphertext, string $key): string
{
    $decoded = hex2bin($ciphertext);
    $nonce = mb_substr($decoded, 0, 24, '8bit');
    $cipher = mb_substr($decoded, 24, null, '8bit');
    return sodium_crypto_secretbox_open($cipher, $nonce, $key);
}

function getSSNBlindIndex(string $ssn, string $indexKey): string
{
    return bin2hex(
        sodium_crypto_pwhash(
            32,
            $ssn,
            $indexKey,
            SODIUM_CRYPTO_PWHASH_OPSLIMIT_MODERATE,
            SODIUM_CRYPTO_PWHASH_MEMLIMIT_MODERATE
        )
    );
}

function findHumanBySSN(PDO $db, string $ssn, string $indexKey): array
{
    $index = getSSNBlindIndex($ssn, $indexKey);
    $stmt = $db->prepare('SELECT * FROM humans WHERE ssn_bidx = ?');
    $stmt->execute([$index]);
    return $stmt->fetchAll(PDO::FETCH_ASSOC);
}

Một bằng chứng toàn diện hơn về khái niệm được bao gồm trong. Nó được phát hành theo giấy phép Creative Commons CC0, mà đối với hầu hết mọi người có nghĩa giống như “phạm vi công cộng”

Phân tích Bảo mật và Hạn chế

Tùy thuộc vào mô hình mối đe dọa chính xác của bạn, giải pháp này để lại hai câu hỏi phải được trả lời trước khi có thể áp dụng

1. Nó có an toàn để sử dụng hay nó rò rỉ dữ liệu như một cái sàng?
2. những hạn chế về tính hữu dụng của nó là gì? . )

Với ví dụ của chúng tôi ở trên, giả sử khóa mã hóa và khóa chỉ mục mù của bạn là riêng biệt, cả hai khóa đều được lưu trữ trong máy chủ web và máy chủ cơ sở dữ liệu không có bất kỳ cách nào để lấy các khóa này, thì bất kỳ kẻ tấn công nào chỉ xâm phạm máy chủ cơ sở dữ liệu ( . Rò rỉ mục nhập trùng lặp này là cần thiết để có thể lập chỉ mục, từ đó cho phép truy vấn CHỌN nhanh từ một giá trị do người dùng cung cấp

Hơn nữa, nếu kẻ tấn công có khả năng vừa quan sát/thay đổi bản rõ với tư cách là người dùng bình thường của ứng dụng vừa quan sát các chỉ số mù được lưu trữ trong cơ sở dữ liệu, thì chúng có thể tận dụng điều này thành một cuộc tấn công bản rõ đã chọn, trong đó chúng lặp lại mọi giá trị có thể với tư cách là người dùng . Điều này thực tế hơn trong kịch bản HMAC so với trong kịch bản điện tử. g. kịch bản Argon2. Đối với các giá trị entropy cao hoặc độ nhạy thấp (không phải SSN), vật lý của vũ lực có thể đứng về phía chúng ta

Một cuộc tấn công thực tế hơn nhiều đối với một tên tội phạm như vậy sẽ là thay thế các giá trị từ hàng này sang hàng khác rồi truy cập ứng dụng một cách bình thường, điều này sẽ tiết lộ văn bản gốc trừ khi sử dụng khóa riêng biệt trên mỗi hàng (e. g. hash_hmac('sha256', $rowID, $masterKey, true) thậm chí có thể là một biện pháp giảm nhẹ hiệu quả ở đây, mặc dù những biện pháp khác sẽ tốt hơn). Cách bảo vệ tốt nhất ở đây là sử dụng chế độ AEAD (chuyển khóa chính dưới dạng dữ liệu được liên kết bổ sung) để các bản mã được liên kết với một hàng cơ sở dữ liệu cụ thể. (Điều này sẽ không ngăn những kẻ tấn công xóa dữ liệu, đây là một thách thức lớn hơn nhiều. )

So với lượng thông tin bị rò rỉ bởi các giải pháp khác, hầu hết các mô hình mối đe dọa của ứng dụng sẽ thấy đây là một sự đánh đổi có thể chấp nhận được. Miễn là bạn đang sử dụng mã hóa được xác thực để mã hóa và HMAC (để lập chỉ mục mù dữ liệu không nhạy cảm) hoặc thuật toán băm mật khẩu (để lập chỉ mục mù dữ liệu nhạy cảm), bạn có thể dễ dàng suy luận về tính bảo mật của ứng dụng của mình

Tuy nhiên, nó có một hạn chế rất nghiêm trọng. Nó chỉ hoạt động cho các trận đấu chính xác. Nếu hai chuỗi khác nhau một cách vô nghĩa nhưng sẽ luôn tạo ra một hàm băm mật mã khác, thì việc tìm kiếm chuỗi này sẽ không bao giờ mang lại kết quả chuỗi kia. Nếu bạn cần thực hiện các truy vấn nâng cao hơn, nhưng vẫn muốn giữ các khóa giải mã và giá trị văn bản gốc của mình ngoài tầm tay của máy chủ cơ sở dữ liệu, chúng tôi sẽ phải sáng tạo

Cũng cần lưu ý rằng, trong khi HMAC/Argon2 có thể ngăn chặn những kẻ tấn công không sở hữu khóa học các giá trị văn bản gốc của những gì được lưu trữ trong cơ sở dữ liệu, nó có thể tiết lộ siêu dữ liệu (e. g. hai người dường như không liên quan chia sẻ một địa chỉ đường phố) về thế giới thực

Triển khai tìm kiếm mờ hơn cho dữ liệu được mã hóa

Trường hợp sử dụng có thể. Mã hóa tên hợp pháp của mọi người và có thể tìm kiếm chỉ bằng các kết quả khớp một phần

Hãy xây dựng trên phần trước, nơi chúng tôi đã xây dựng một chỉ mục mù cho phép bạn truy vấn cơ sở dữ liệu để tìm các kết quả khớp chính xác

Lần này, thay vì thêm các cột vào bảng hiện có, chúng tôi sẽ lưu trữ các giá trị chỉ mục bổ sung vào một bảng tham gia

CREATE TABLE humans (
    humanid BIGSERIAL PRIMARY KEY,
    first_name TEXT, /* encrypted */
    last_name TEXT, /* encrypted */
    ssn TEXT, /* encrypted */
);
CREATE TABLE humans_filters (
    filterid BIGSERIAL PRIMARY KEY,
    humanid BIGINT REFERENCES humans (humanid),
    filter_label TEXT,
    filter_value TEXT
);
/* Creates an index on the pair. If your SQL expert overrules this, feel free to omit it. */
CREATE INDEX ON humans_filters (filter_label, filter_value);

Lý do cho sự thay đổi này là để chuẩn hóa cấu trúc dữ liệu của chúng tôi. Bạn có thể hoàn thành chỉ bằng cách thêm các cột vào bảng hiện có, nhưng nó có thể trở nên lộn xộn

Thay đổi tiếp theo là chúng tôi sẽ lưu trữ một chỉ mục mù riêng biệt, riêng biệt trên mỗi cột cho mọi loại truy vấn khác nhau mà chúng tôi cần (mỗi loại có khóa riêng). Ví dụ

• Cần tra cứu phân biệt chữ hoa chữ thường bỏ qua khoảng trắng?
  • Lưu trữ một chỉ số mù của preg_replace('/[^a-z]/', '', strtolower($value))
• Cần truy vấn chữ cái đầu tiên trong họ của họ?
  • Lưu trữ một chỉ số mù của

    CREATE TABLE humans (
    
        humanid BIGSERIAL PRIMARY KEY,
        first_name TEXT,
        last_name TEXT,
        ssn TEXT, /* encrypted */
        ssn_bidx TEXT /* blind index */
    );
    CREATE INDEX ON humans (ssn_bidx);
    

    0
• Cần ghép “chúng sinh có chữ này, kết thúc bằng chữ kia”?
  • Lưu trữ một chỉ số mù của

    CREATE TABLE humans (
    
        humanid BIGSERIAL PRIMARY KEY,
        first_name TEXT,
        last_name TEXT,
        ssn TEXT, /* encrypted */
        ssn_bidx TEXT /* blind index */
    );
    CREATE INDEX ON humans (ssn_bidx);
    

    0
• Cần truy vấn ba chữ cái đầu tiên của họ và chữ cái đầu tiên của tên họ?
  • Bạn đoán nó. Xây dựng một chỉ mục khác dựa trên một phần dữ liệu

Mỗi chỉ mục cần phải có một khóa riêng biệt và cần phải nỗ lực hết sức để ngăn chặn các chỉ mục mù của các tập hợp con của bản rõ làm rò rỉ các giá trị thực của bản rõ cho một tên tội phạm có sở trường giải ô chữ. Chỉ tạo các chỉ mục cho các nhu cầu kinh doanh nghiêm túc và đăng nhập quyền truy cập vào các phần này trong ứng dụng của bạn một cách tích cực

Giao dịch ký ức lấy thời gian

Cho đến nay, tất cả các đề xuất thiết kế đều ủng hộ việc cho phép các nhà phát triển viết các truy vấn CHỌN được cân nhắc cẩn thận, đồng thời giảm thiểu số lần chương trình con giải mã được gọi. Nói chung, đó là nơi đoàn tàu dừng lại và mục tiêu của hầu hết mọi người đã được đáp ứng

Tuy nhiên, có những tình huống mà hiệu suất thấp trong các truy vấn tìm kiếm có thể chấp nhận được nếu điều đó có nghĩa là tiết kiệm được nhiều dung lượng ổ đĩa

Bí quyết ở đây rất đơn giản. Cắt bớt các chỉ mục mù của bạn thành e. g. 16, 32 hoặc 64 bit và coi chúng là bộ lọc Bloom

• Nếu các chỉ số mù liên quan đến truy vấn khớp với một hàng nhất định, dữ liệu có thể khớp
  • Mã ứng dụng của bạn sẽ cần thực hiện giải mã cho từng hàng ứng cử viên và sau đó chỉ phục vụ các kết quả phù hợp thực tế
• Nếu các chỉ số mù liên quan đến truy vấn không khớp với một hàng nhất định, thì dữ liệu chắc chắn không khớp

Cũng có thể đáng để chuyển đổi các giá trị này từ một chuỗi thành một số nguyên, nếu máy chủ cơ sở dữ liệu của bạn sẽ lưu trữ nó hiệu quả hơn

Phần kết luận

Tôi hy vọng mình đã chứng minh đầy đủ rằng không chỉ có thể xây dựng một hệ thống sử dụng mã hóa an toàn đồng thời cho phép truy vấn nhanh (với mức rò rỉ thông tin tối thiểu trước những kẻ tấn công có đặc quyền), mà còn có thể xây dựng một hệ thống như vậy một cách đơn giản, từ

Nếu bạn quan tâm đến việc triển khai lưu trữ cơ sở dữ liệu được mã hóa vào phần mềm của mình, chúng tôi muốn cung cấp cho bạn và công ty của bạn các dịch vụ tư vấn của chúng tôi. Liên hệ với ParagonIE nếu bạn quan tâm

Làm cách nào để tìm kiếm dữ liệu được mã hóa trong MySQL?

Làm cách nào để tìm kiếm dữ liệu được mã hóa trong máy chủ SQL?

Làm cách nào để kiểm tra xem bảng có được mã hóa trong MySQL không?

Làm cách nào tôi có thể xem dữ liệu được mã hóa?