Accessをリモート環境で安全に使う方法｜VPN・遠隔操作の選び方

概要

この記事でわかること

• VPNによる接続とリモートデスクトップによる画面転送の違い
• 社内PC、RDS、AVD、SQL Server連携を選ぶときの判断基準
• 多要素認証、アクセス権、データ持ち出しへの対策
• 利用者別のAccess配置と切断・復元を含む試験の進め方

この記事の主な内容

1. Accessを安全にリモート利用するための基本
2. Accessのリモート利用方式を比較する
3. 不正アクセスと情報持ち出しを防ぐ
4. Access特有の配置と同時利用を確認する
5. 通信切断や障害に備えて運用を決める
6. 検証から本番利用へ進める5つの手順
7. よくある質問
8. まとめ

想定読了時間：約14分～17分

1 Accessを安全にリモート利用するための基本

Accessのリモート利用とは、社外から社内PCや仮想デスクトップ上のAccessを操作するなどして、離れた場所で業務データを利用する運用です。構成を考えるときは、「どこでAccessが動くか」「データはどこにあるか」「どの経路でつなぐか」を確認します。

VPNは接続経路であり画面転送とは役割が異なる

VPNは、インターネットなどを通じて社内ネットワークへ接続するための仕組みです。一方、リモートデスクトップは、別のPCやサーバーで動くアプリケーションを手元の端末から操作する方式です。VPNで社内に接続してから、社内PCへリモートデスクトップ接続する構成もあります。

重要なのは、VPNにつながった後の動きです。自宅PCのAccessから社内のACCDBを開く場合、データファイルへの通信が遠隔回線を通ります。社内PC上のAccessを遠隔操作する場合は、AccessとDBの通信を社内側に置き、手元の端末とは主に画面や操作情報をやり取りします。

共有ファイルを遠隔回線越しに開く構成は避ける

Microsoftは、WANやAzureファイル共有で分割Accessデータベースを使うと、動作が遅くなったり、DBが破損したりするおそれがあるため、避けるよう案内しています。VPNで通信を保護しても、回線遅延や切断によるファイルアクセスの問題がなくなるわけではありません。[S1]

画面転送を採用する際も、実行側のAccessが遠く離れた拠点のACCDBを参照していれば、その区間に課題が残ります。Accessとファイル型DBの間は安定したLAN内に置くことを基本にし、クラウド上でのファイル配置・共有方式は公式の注意事項に照らして確認します。

2 Accessのリモート利用方式を比較する

既存の画面や帳票を使い続けたい場合は、社内PCへの遠隔接続や、RDS・AVDによる画面転送が候補になります。データ管理を強化したい場合は、Accessを画面として残し、データをSQL Serverなどへ移す構成も比較します。方式は併用でき、利用者数だけでは決まりません。

社内PC方式は、接続先PCが停止すると使えなくなる点まで含めて運用を考えます。また、通常のWindowsクライアントPCを、複数人が独立して同時利用するサーバーの代わりにできるとは限りません。複数人利用はOSの機能、契約条件、実行環境を確認して設計します。

RDSはWindows Serverのリモートデスクトップサービスで、RemoteAppはアプリのウィンドウを利用者に公開する機能です。AVDはAzure Virtual Desktopの略で、Azureの仮想デスクトップサービスです。いずれもAccessがWindows環境で動く構成であり、Access自体をWebアプリへ変換するものではありません。[S1][S7]

SQL Server連携とWeb化を検討する条件

SQL ServerやAzure SQL Databaseへ移すと、DB側の認証・権限やデータ処理を活用できます。ただし、移行だけで速くなるとは限りません。大量のデータをAccessへ取り込んでから絞り込む処理や、1件ずつ通信する更新処理があれば、抽出・集計をDB側で行えるか見直します。[S9]

ブラウザーでの操作、社外ユーザーの利用、スマートフォン向け画面が必要なら、Web化も検討対象です。比較する費用には、構築・改修だけでなく、接続基盤、利用権、クラウド稼働、保守を含めます。既存環境が異なるため、どの方式が最安かを一律には決められません。

OneDriveやSharePointの文書保存機能で代用しない

OneDriveやSharePointの文書ライブラリにAccessファイルを置き、そこから開く運用は避けます。Microsoftは、編集とアップロードの過程で複数のコピーができ、予期しない動作が起こり得ると説明しています。これはSharePointリストのデータをAccessから利用する方式とは別です。[S2]

3 不正アクセスと情報持ち出しを防ぐ

安全性は、接続方式の名称だけでは判断できません。誰が、どの端末から、どのデータへアクセスし、どこへ出力できるかを決めます。導入時の設定に加えて、更新、ログ確認、退職・異動時の権限変更まで担当を割り当ててください。

接続入口を保護し利用者を本人確認する

RDPはリモートデスクトップの通信方式です。接続先のRDPを安易にインターネットへ直接公開せず、管理されたVPN、RD Gateway、AVDなど、構成に合った接続基盤を使います。RD Gatewayは社外から社内資源へ接続するゲートウェイで、証明書、接続許可、利用先の制限などを設定します。[S4]

多要素認証は、パスワード以外の確認手段も使って本人を確認する仕組みです。接続入口や管理者アカウントに適用し、共有IDを避けて利用者ごとのIDで運用します。製品を導入しただけで全経路に適用されるとは限らないため、別の接続経路で認証を迂回できないかも確認します。[S3][S4]

必要な権限に絞り端末を管理する

日常業務の利用者には、必要なアプリ・フォルダー・DBへの権限を与え、管理者権限は分けます。共有フォルダーでは、Accessの正常動作に必要な権限も確認してください。保護のために書込みを一律禁止すると、更新やロックファイルの作成ができず、業務が止まる場合があります。[S1][S3]

接続元と実行側の両方で、OSやアプリの更新、端末保護、画面ロックを管理します。私物PCを認める場合は、会社管理端末と同じ条件を満たせるかが判断点です。会社の方針に合わない端末を、接続できるという理由だけで利用対象に含めないようにします。

画面転送でもコピーや印刷の出口を確認する

画面転送では、クリップボード、ローカルドライブ、プリンターなどを実行側へ接続する「リダイレクト」が利用できる場合があります。必要な機能だけを許可し、設定が実際の接続クライアントでも効くかを試します。[S11]

方向やデータ種類ごとの制限は、OSや接続クライアントの対応状況によって使える範囲が異なります。必要な制御ができない場合は、転送自体を無効にするか、別の受け渡し方法を用意します。[S11]

ただし、ドライブ転送を止めても、実行側のブラウザーやメールから外部へ送れる場合があります。画面の撮影も別の問題です。「端末にデータが一切残らない」と断定せず、アプリの利用制限と業務ルールを組み合わせます。RemoteAppでAccessだけを表示しても、それ自体が他の操作を防ぐセキュリティ機能になるわけではありません。[S3]

接続ログは、利用者、時刻、接続結果などを追跡できるようにします。一方、誰がどの業務データを変更したかは、AccessやDB側の記録が必要です。認証ログだけで更新履歴まで把握できるとは限らないため、必要な記録の範囲と確認担当を決めます。

4 Access特有の配置と同時利用を確認する

リモート基盤が整っても、Accessの配置や依存部品が合わなければ正常に動きません。画面の表示だけで判断せず、入力、検索、取込、印刷、外部連携まで、実際の業務を一通り動かして確認します。

フロントエンドは実行側で利用者別に配置する

複数人で使う場合は、フォーム・クエリ・VBAなどを含むフロントエンドと、データを保持するバックエンドを分けます。各利用者が自分のフロントエンドのコピーから共通DBへ接続する構成にします。[S8]

この「自分のコピー」は、画面転送では接続先の実行環境に置きます。同じサーバーに接続する利用者全員が、同じフロントエンドファイルを開く運用にしないでください。利用者専用の作業領域を用意し、どのサーバーへ接続しても正しい版を起動できる配布方法を決めます。

さらに、利用者Aが同じ受注を編集中に利用者Bが更新した場合の動作も試します。更新競合の通知や再読込みを確認し、どちらの変更が保存されたか分からない状態を残さないことが大切です。自動処理やExcel連携が同じデータを書き換える場合も、試験対象に含めます。

ACCDEとRuntimeの役割を混同しない

ACCDEは、VBAやフォーム・レポートなどの設計変更を制限する配布形式です。Runtimeは、製品版Accessを持たない利用者向けの実行環境です。どちらも、利用者認証やDBのアクセス権を代替する仕組みではありません。[S1]

配布用にACCDEを使う場合も、改修できる原本ACCDBを保管し、版を管理します。プログラム更新では、利用者がAccessを終了した状態で専用コピーを置き換えるなど、使用中ファイルを上書きしない手順を用意します。旧版へ戻す場合は、DB側の変更との互換性も確認します。

実行環境と印刷先の違いを確認する

Windowsが64bitでも、OfficeやAccessが32bitの構成はあります。移行先ではAccessの版・bit数に加えて、ODBCドライバー、ActiveX・OCX、DLL、VBAの参照設定などの依存関係を確認します。既存PCと同じように起動できても、特定のボタン操作だけ失敗することがあるためです。

また、「デスクトップへ出力」という処理は、接続先Windowsのデスクトップへ保存されることがあります。手元PCへの保存と区別し、固定ドライブ名や個人フォルダーに依存した処理も見直します。帳票は、用紙サイズ、改ページ、フォント、プリンターの選択まで実機で確認してください。

接続基盤とOfficeの利用権を分けて確認する

RDSの利用権、AVDの利用条件、Access・Officeの利用権は別々に確認します。Windows ServerのRDSセッションホストを使う場合は、利用者またはデバイスに必要なRDS CALなどを確認し、管理作業用の接続を一般業務の代わりにしないでください。[S6]

Microsoft 365 Appsを複数人の共有コンピューターで使う場合は、共有コンピューター認証に対応する契約が必要です。Microsoft 365 Business Standardはこの認証に対応しません。Runtimeを採用しても、接続基盤の利用権や、連携して動かすExcelなどの確認まで不要になるわけではありません。[S5][S7]

今のAccessを社外から安全に使う構成を整理しませんか

既存Accessの保存先や外部連携が分からない場合は、先に構成を調べると、必要な対策を絞れます。
Accessの保守・改修やSQL Server移行の観点から、継続利用できる部分と見直しが必要な部分の整理をご相談いただけます。

5 通信切断や障害に備えて運用を決める

障害対策は、再接続できることだけで完了しません。更新結果を確認できること、必要な時点のデータへ復元できること、担当者が判断できることまで準備します。ここでは、導入時に決めておきたい運用例を説明します。

切断とサインアウトを区別する

リモート画面を閉じる「切断」と、Windowsの利用を終了する「サインアウト」は動作が異なります。切断後も接続先で処理が続く場合がありますが、タイムアウト設定、再起動、サーバー障害などで終了する可能性もあります。放置した処理が必ず完了するとは考えないでください。

例えば、CSV取込の途中で画面が切れたときは、すぐに同じ取込を実行せず、同じセッションへ戻れるか確認します。そのうえで、取込履歴、対象件数、管理番号などから完了範囲を調べます。再実行で二重登録が起きるなら、重複確認や処理単位の記録をアプリ側に追加する必要があります。

利用終了時の手順は、「入力を保存する」「Accessを閉じる」「必要に応じてサインアウトする」と具体化します。無操作や切断後の強制終了時間は、長時間の取込・集計と衝突しないよう決め、利用者にも周知します。[S3]

バックアップはデータの保存先で取得する

分割構成では、フロントエンドだけをコピーしても業務データのバックアップにはなりません。Accessファイルにデータがある場合はバックエンドを、SQL Serverなどにある場合はDB側の仕組みを使って保護します。原本ACCDBや接続設定も、復旧に必要なものとして別途管理します。[S10]

Accessのバックアップでは、利用者に保存・終了を依頼し、排他的にアクセスできる状態を確保する方法が基本です。開いたままのファイルを単純にコピーする運用を、整合性の保証されたバックアップとみなさないでください。保存先のアクセス権と世代管理も定めます。[S10]

復元の試験と担当者を決める

取得したバックアップは、業務から切り離した別環境へ復元して確認します。ファイルが開くことに加え、件数、主要な金額、直近の更新、帳票結果まで照合します。テスト用Accessが誤って本番DBや送信先へ接続しないよう、リンク先と外部連携も切り替えてください。

復旧までの目標時間をRTO、どの時点までのデータ損失を許容するかをRPOと呼びます。例えば「停止は2時間まで」「失ってよい更新は最大1時間分」という業務要件なら、その条件を満たす取得頻度と復元手順が必要です。これは考え方の例であり、製品の保証値ではありません。

また、接続障害は基盤担当、更新不明はAccess担当、復元と業務再開はデータ管理者・業務責任者、というように役割を決めます。兼任する場合も、連絡先と判断手順を残し、特定の担当者が不在でも対応できる状態にします。

6 検証から本番利用へ進める5つの手順

導入は、少人数で実際の業務を試し、結果を確認してから広げます。以下は進め方の例です。安全対策を設定した証拠と、業務が正常に完了した記録をそろえると、本番移行の判断がしやすくなります。

手順1 現在の構成と業務を把握する

Accessの実行場所、DB保存先、利用者数、ピーク時の同時利用、連携システムを一覧にします。毎日の入力だけでなく、月末帳票や大量取込も含めてください。機密データの範囲と、持ち出し・印刷が必要な業務も確認します。

手順2 方式と保護方針を決める

社内PC、RDS、AVDなどの候補を比較し、DBの配置と通信経路を決めます。認証、権限、持ち出し制御、更新担当、復旧目標までまとめ、契約条件と継続費用を確認します。管理された既存基盤で要件を満たせるなら、その活用も検討できます。

手順3 検証環境と復元手段を用意する

本番から分離した環境を作り、マスキングしたデータなどを使って確認します。必要なAccess・ドライバー・外部部品をそろえ、利用者別のフロントエンドを配置します。変更前の設定とバックアップも残して、試験に失敗した場合の戻し方を用意します。

手順4 実業務と切断時の動きを試す

「ログインできた」「フォームが開いた」だけでは不十分です。普段の処理に加えて、同時更新、印刷、出力制限、再接続、復元を試します。処理時間は社内利用時と同じデータ・操作で測り、業務上許容できるかを利用者と確認します。

手順5 本番移行と運用記録を始める

試験結果を業務責任者と確認し、切替日時、利用者への案内、障害連絡先を共有します。開始後は、接続失敗、処理時間、競合、出力エラーを記録してください。退職・異動時の権限停止と、OS・アプリ更新後の確認も定期運用に組み込みます。

切り戻す場合は、新環境で更新したデータを先に保全します。特にDB保存先まで変更した場合、古いDBへ単純に戻すと切替後の入力が失われます。利用を止める条件、正本とするDB、差分の扱い、戻し作業の担当を事前に決めておきましょう。

よくある質問（FAQ）

まとめ

Accessのリモート利用では、実行場所とデータ保存先を確認したうえで、業務に合う接続方式を選びます。画面転送を使う場合も、本人確認、権限、持ち出し制御、利用者別の配置が必要です。最後に、切断後の更新確認と復元を試し、正常に業務を再開できる状態にしてから本番利用を始めてください。

Accessのリモート利用についてご相談ください

VPN接続時の遅さ、複数人利用、帳票・外部連携の不具合などでお困りの場合は、現在の構成から整理できます。
ご相談の際は、Accessのバージョン、DB保存先、同時利用者数、困っている操作をお知らせください。既存環境の改修、SQL Server移行、Web化を含めて検討するための材料になります。

参考情報

[S1] Accessアプリケーションの配布
参照内容：WAN利用の注意、RDS、配布形式とRuntime

[S2] Accessデスクトップデータベースの共有方法
参照内容：共有構成とOneDrive・SharePoint文書ライブラリの注意

[S3] Azure Virtual Desktopのセキュリティ推奨事項
参照内容：認証、権限、端末保護、セッションとアプリの制御

[S4] Remote Desktop Servicesの社外からの接続
参照内容：RD Gateway、証明書、認証とアクセス許可

[S5] Microsoft 365 Appsの共有コンピューター認証
参照内容：対応プランとユーザーごとの利用権

[S6] RDSクライアントアクセスライセンス
参照内容：RDS CALと利用者・デバイスのライセンス

[S7] Azure Virtual Desktopの前提条件
参照内容：OS、ID、ネットワーク、利用権

[S8] Accessデータベースの分割
参照内容：フロントエンドの利用者別配布とバックエンドの共有

[S9] AccessデータベースのSQL Server移行
参照内容：データ基盤の移行とサーバー側処理

[S10] バックアップと復元によるAccessデータの保護
参照内容：バックアップ対象、排他アクセス、復元

[S11] RDPのクリップボードリダイレクト設定
参照内容：転送制御、対応環境、設定後の動作確認