タグ

暗号化とdbに関するgouei2001のブックマーク (4)

  • MySQL 5.7の透過的データ暗号化 - Qiita

    MySQL 5.7.11で導入、5.7.12で一部改良された、透過的データ暗号化をテストしたときのメモです。 とある勉強会のLTでグダグダになったので、あらためて書き直して投稿しておきます。 ※内容は無保証です。 2019/04/30 追記: MySQL 8.0 については以下の記事をご覧ください。 MySQL 8.0.16 でテーブルスペース・REDO ログ/UNDO ログ・システムテーブル暗号化 透過的データ暗号化(TDE)とは アプリケーション(SQL)側で暗号化/復号処理をしなくても、DBのデータファイルが暗号化される機能です。 データファイルや物理メディア(HDDなど)の窃取・盗難対策に有効です。 一方で、アプリケーション側にSQLインジェクションなどの脆弱性がある場合には、何の保護にもなりません。 MySQL以外のRDBMSでは 商用のOracleなどでは、かなり前から使えるよ

    MySQL 5.7の透過的データ暗号化 - Qiita
  • データベースに関わる暗号化を考える

    1.データベースと暗号化 データベースにかかわる暗号化については、その対象とする脅威とその対策によって以下のようなポイントがあります。 ネットワーク上の盗聴に対して通信経路の暗号化を行う OSレベルでのファイル盗難、バックアップメディアの盗難などに対して格納データの暗号化を行う。 バックアップメディア内のデータのみ暗号化を行う。 「2.」と「3.」は似ていますが、データベースを取り巻く実際の脅威と、既に実施されている各種のセキュリティ対策を合わせて考えたとき「稼働しているサーバー自体は十分保全されていてリスクは小さいので性能優先にしたいが、バックアップメディアの輸送中や倉庫管理などについては対策が必要」といったような場合に「3.」を選択するケースもあると考えられます。 今回はこの中で特に「2.」の「格納データの暗号化」について取り上げてみたいと思います。 2.データベースの暗号化が対応する

  • suz-lab.com - suz lab リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

  • 暗号化する場合のmysqlのテーブル | In Mars

    アカウント管理の続き。passwordの保存については前回書いた。emailの暗号化だが、mysqlのAES_ENCRYPT()関数とAES_DECRYPT関数を使えば良いらしい。MySQLのDocumentにも今のところ一番安全と書かれている。 MySQLに暗号化したデータを保存するには、BLOB型にしなければいけないと。そんなわけで、MySQLのテーブルは、以下のようになる。テーブル名はaccountにしよう。 id int primary key auto_increment account varchar(128) p_hash varchar(256) email TINYBLOB p_hashはpasswordの保存のところで作った、salt付きパスワードのハッシュを入れる。暗号化したemailはTINYBLOB型のemailに入れる。sha1のhash256バイトもないだろ。

  • 1