りおんクロニクル

SQLite × セキュリティ完全ガイド｜暗号化・パスワード・保護戦略【2026年版】

Home ＞ 【2026年版】C# / .NET入門と実践ガイド｜基礎・業務アプリ開発・SQLite連携まで体系的に解説

SQLiteは「1ファイルで完結する」軽量DBですが、 そのシンプルさゆえにセキュリティ設計を間違えると一瞬で情報漏えいにつながります。 この記事では、SQLiteの暗号化・パスワード・配置・バックアップまで、 現場目線で押さえるべきポイントを整理します。

この記事でわかること
・SQLiteファイルのセキュリティリスク
・暗号化SQLite（SQLCipherなど）の考え方
・C#アプリでの保護戦略（パスワード・キー管理）
・安全な配置場所と権限設定
・バックアップ時のセキュリティ注意点
・業務アプリ向けベストプラクティス

1. SQLiteのセキュリティリスクを正しく理解する

SQLiteは「.dbファイルをコピーすれば中身が丸見え」という性質があります。 つまり、次のような状況がそのままリスクになります。

重要： 「アプリにログイン機能がある＝DBが安全」ではありません。 SQLiteファイル自体をコピーされると、アプリを通さず中身を見られます。

2. セキュリティ対策のレイヤー構造

SQLiteのセキュリティは、次のレイヤーで考えると整理しやすいです。

  1. 物理レイヤー： ファイルの配置場所・OS権限
  2. 暗号化レイヤー： DBファイル自体の暗号化
  3. アプリレイヤー： 認証・認可・入力制御
  4. バックアップレイヤー： コピー・世代管理・持ち出し

この記事では特に①物理＋②暗号化＋④バックアップを中心に扱います。

3. まずは「配置場所」と「OS権限」を固める

■ やってはいけない配置

■ 推奨配置（Windowsデスクトップアプリの場合）

「まずはOSレベルで守る」のが最初の一歩です。 そのうえで、必要に応じて暗号化を検討します。

4. SQLiteの暗号化の考え方

標準のSQLiteは暗号化機能を持っていません。 暗号化を行うには、以下のような手段が必要です。

ざっくり整理
・「DB全体を守りたい」 → SQLCipherなど暗号化SQLite
・「PCごと守りたい」 → BitLockerなどフルディスク暗号化
・「一部の情報だけ守りたい」 → アプリ側で暗号化して保存

5. C#アプリでの「機微情報だけ暗号化」パターン

「SQLCipher導入までは重いけど、何も守らないのは怖い」 という場合に現実的なのが、特定カラムだけアプリ側で暗号化するパターンです。

■ 例：メールアドレスだけ暗号化して保存

using System.Security.Cryptography;
using System.Text;

public static class CryptoHelper
{
    // 実運用ではキーはハードコードせず、OSの保護ストアなどに置く
    private static readonly byte[] Key = Encoding.UTF8.GetBytes("your-32byte-secret-key-here!!");
    private static readonly byte[] Iv  = Encoding.UTF8.GetBytes("your-16byte-iv-here!");

    public static string Encrypt(string plain)
    {
        using var aes = Aes.Create();
        aes.Key = Key;
        aes.IV  = Iv;

        using var encryptor = aes.CreateEncryptor();
        var bytes = Encoding.UTF8.GetBytes(plain);
        var cipher = encryptor.TransformFinalBlock(bytes, 0, bytes.Length);
        return Convert.ToBase64String(cipher);
    }

    public static string Decrypt(string cipherText)
    {
        using var aes = Aes.Create();
        aes.Key = Key;
        aes.IV  = Iv;

        using var decryptor = aes.CreateDecryptor();
        var bytes = Convert.FromBase64String(cipherText);
        var plain = decryptor.TransformFinalBlock(bytes, 0, bytes.Length);
        return Encoding.UTF8.GetString(plain);
    }
}

■ SQLiteへの保存時

var emailEncrypted = CryptoHelper.Encrypt(user.Email);

var sql = "INSERT INTO Users (Name, Email) VALUES (@name, @mail)";
using var cmd = new SqliteCommand(sql, con);
cmd.Parameters.AddWithValue("@name", user.Name);
cmd.Parameters.AddWithValue("@mail", emailEncrypted);
cmd.ExecuteNonQuery();

■ 読み出し時

var emailEncrypted = reader.GetString(2);
var email = CryptoHelper.Decrypt(emailEncrypted);

この方式なら、DBファイルをコピーされてもメールアドレスは平文で読めない状態にできます。 （ただし、キー管理が甘いと意味がなくなるので注意）

6. キー・パスワードの管理で絶対にやってはいけないこと

■ NGパターン

■ 現実的な対策案（デスクトップアプリ想定）

■ DPAPIの簡易例

using System.Security.Cryptography;
using System.Text;

public static class ProtectedStore
{
    public static void Save(string path, string plain)
    {
        var bytes = Encoding.UTF8.GetBytes(plain);
        var protectedBytes = ProtectedData.Protect(
            bytes, null, DataProtectionScope.CurrentUser);
        File.WriteAllBytes(path, protectedBytes);
    }

    public static string Load(string path)
    {
        var protectedBytes = File.ReadAllBytes(path);
        var bytes = ProtectedData.Unprotect(
            protectedBytes, null, DataProtectionScope.CurrentUser);
        return Encoding.UTF8.GetString(bytes);
    }
}

これにより、同じPCの同じユーザー以外からは復号できない形で秘密情報を保存できます。

7. バックアップ時のセキュリティ注意点

バックアップは「コピーが増える＝リスクも増える」ということです。

■ 注意すべきポイント

■ 推奨パターン

8. ログ・一時ファイルにも注意する

アプリのログや一時ファイルに、 SQLや機微情報をそのまま書き出していないかも要チェックです。

9. 業務アプリ向けベストプラクティスまとめ

まとめ：SQLiteは「軽い」からこそ、セキュリティ設計がすべて

「軽くて便利」なSQLiteは、同時に「軽く持ち出されやすい」DBでもあります。 この記事をベースに、アプリの規模や重要度に合わせて、 無理のないセキュリティレベルを設計してみてください。

前のページ　 次のページ