2025.03.10 2025.03.10

【初心者向け】Accessのセキュリティと基本的なバリデーション

nanikatoaccess

以下では、「セキュリティと基本的なバリデーション」をテーマに、Accessで開発したアプリケーションを安全に運用するためのポイントを解説します。デスクトップDBだからこそつい見落としがちな脆弱性や、**入力チェック（バリデーション）**の重要性について、初心者でも分かりやすいようにまとめました。

1. なぜセキュリティ対策とバリデーションが必要か

Accessで作られたシステムは、Excel管理と比べれば同時アクセスやデータ整合性に強い一方、セキュリティはあまり意識されないまま運用されることが多々あります。しかし、顧客情報や注文情報などの機密データを扱う以上、最低限の対策は必須です。

ポイント

意図せぬデータ改ざんや不正アクセスを防ぎたい

入力ミスや誤登録をシステム側でカバーし、業務の信頼性を高めたい

Accessファイルが漏えいした場合でも、パスワードや権限設定で被害を最小限にしたい

2. 入力バリデーション（基本的なチェック）

ないものはない！お買い物なら楽天市場

2.1 フィールドレベルのバリデーション

Accessテーブルの設計時に、各フィールド（列）ごとにバリデーションルールや必須入力の設定ができます。

必須プロパティ: Required を Yes にすると、空欄（Null）を許可しない
入力規則 (Validation Rule): 例）[数量]>=0 でマイナス値を禁止
入力規則メッセージ (Validation Text): ルール違反時に表示されるメッセージを設定

これらをテーブルレベルで定義すると、クエリやフォームを介して入力が行われる場合でも、自動的に整合性が保たれます。

2.2 フォームやイベントでのバリデーション

フォームのBeforeUpdateイベント: レコード更新直前に、各コントロールの値を細かくチェックできる
コントロールのBeforeUpdate / AfterUpdateイベント: 特定フィールドの入力終了時に、文字数制限や数値・日付の形式確認などを行う

例: テキストボックスのNull禁止 (VBA)

Private Sub txt顧客名_BeforeUpdate(Cancel As Integer)
    If IsNull(Me.txt顧客名) Or Me.txt顧客名 = "" Then
        MsgBox "顧客名は必須入力です。", vbExclamation
        Cancel = True
    End If
End Sub

フィールドレベルの制約だけでなく、UI段階で詳細なエラー通知を実装するとユーザーが操作しやすくなります。

3. フォームやクエリでのSQLインジェクション対策

SQLインジェクションとは、悪意ある入力値をもとにデータベース操作が意図しない形で実行される手法です。Accessのフォームやクエリで、文字列連結によるSQL文生成をしている場合、インジェクションリスクが高まります。

3.1 文字列連結の危険性

Dim strSQL As String
strSQL = "SELECT * FROM 顧客 WHERE 顧客名 = '" & Me.txt顧客名 & "'"
' ユーザーが txt顧客名 に "hoge' OR '1'='1" と入力したら
' -> "SELECT * FROM 顧客 WHERE 顧客名 = 'hoge' OR '1'='1'"
' となり、全レコードが返される等の不正結果が起こる可能性

3.2 安全な対策

パラメータクエリ: ADOやDAOでパラメータを使う方法
置換処理: ' を '' に変換する最低限のエスケープ
フォームやテーブルの入力規則: 特殊文字や半角カナなどの入力を制限
ストアドプロシージャ(SQL Server連携時): パラメータ化されたプロシージャを呼び出す

例: ADOでパラメータ使用 (VBA)

Dim cmd As ADODB.Command
Set cmd = New ADODB.Command
cmd.ActiveConnection = cn
cmd.CommandText = "SELECT * FROM 顧客 WHERE 顧客名 = @顧客名"
cmd.CommandType = adCmdText

cmd.Parameters.Append cmd.CreateParameter("@顧客名", adVarWChar, adParamInput, 50, Me.txt顧客名)

Dim rs As ADODB.Recordset
Set rs = cmd.Execute

文字列連結を避け、パラメータバインドすることでSQLインジェクションを大幅に抑止。

4. Accessファイル自体のセキュリティ

4.1 パスワード保護と暗号化

Accessにはデータベースのパスワード設定（データベース暗号化）が可能です。

[ファイル] → [情報] → [データベースを暗号化する] でパスワードを設定
これにより、ファイルを開く際にパスワードが求められる
ただし、Officeの仕組み上、強固な暗号化ではないため、完全な防御にはならないことを念頭に

4.2 MDE/ACCDEでソースコードを秘匿

フォームやレポート、VBAのソースコードをユーザーが閲覧・改変できないようにするために、MDE/ACCDE形式にコンパイルして配布する
VBAプロジェクトにパスワードを設定する方法もあるが、こちらも完全ではない（解析ツールが存在する）ため、あくまで簡易ロックと考え、機密情報（接続パスワード等）はさらに別の方法で保護を検討

4.3 共有フォルダと権限設定

Accessファイルを共有フォルダに置く運用はよく見られますが、以下の点に注意：

読み取り専用ユーザーや編集可能ユーザーなどのNTFSアクセス権限を明確に分ける
マルチユーザー運用の場合、フロントエンド分割（各ユーザーPCに .accde配布）を推奨
バックアップやウイルス対策を定期実施

5. SQL Server連携やクラウド活用時のセキュリティ

AccessをSQL ServerやAzure SQL Databaseなどに接続して大規模運用する場合、データはサーバー側で管理され、Accessはフロントエンドとなります。

**Windows認証（Active Directory）**を使うと、接続文字列にパスワードを記載せずに済むため安全。
SQL認証の場合は、Access側にユーザーIDとパスワードが必要なので、DSNレス接続でも暗号化や保護を検討。
VPNやExpressRouteなど、ネットワークレベルの暗号化にも気を配る。
SQL Server側では必要最小限の権限（SELECT, INSERT など）を付与し、dbo権限を安易に与えない。

6. ログや監査で不正やエラーを早期発見

ログテーブル: 更新操作やインポート、エクスポートなどの履歴をAccess内やテキストファイルに書き込み、後々のトラブルシュートを助ける
イベントビューア: WindowsのイベントログにAccess起動・エラー情報などを記録（VBAコードで書き込みも可能）
SQL Server監査（連携時）: 誰がいつどの操作をしたかをDB側で記録しておくと、万一の不正使用があっても追跡可能

7. まとめ：セキュリティとバリデーションで安全・信頼性を高めよう

フォームやテーブルでの必須入力・ルール設定 → ミスやNull登録を減らす
SQLインジェクション対策 → パラメータ化や最低限のエスケープ処理を徹底
Accessファイル保護 → パスワード・暗号化・MDE/ACCDE化・権限設定などで漏えいリスクを下げる
ネットワークとDB権限 → 大規模連携の場合、Windows認証・VPN等で安全な経路を確保
ログと監査 → 不審な操作やエラーの原因を後から調べられる仕組みを作る

Accessはスモールスタートがしやすい反面、セキュリティ面の意識が薄いまま運用に入ってしまう事例も少なくありません。データ活用の自由度と基本的な安全対策をバランス良く両立し、実務で信頼されるシステムを構築してみてください。

関連記事

マクロとイベントプロシージャの基礎

Accessクライアントの配布・バージョン管理

バックアップ・リカバリと災害対策

セキュリティ対策とバリデーションは、業務システムの信頼性を左右する重要項目です。ちょっとした設定やチェックを怠ると、後々重大なトラブルにつながる恐れがありますので、ぜひこの機会にしっかり押さえておきましょう。

DMM

ABOUT ME