(登録済み) ユーザーが (クライアント側およびサーバー側の検証後) (非常に珍しい拡張子で圧縮された) アクセス データベースを asp.net Web フォームを介してサーバーにアップロードできるプロセスを作成しました。アクセスデータベースからSQLサーバーに関連データを流すために、スケジュールされたSSISパッケージが夜間に来るまで、安全な場所に保管してください。
その後、私のアクセスデータベースは削除されます。そのデータベースの他の実行はありません。Access がサーバーにインストールされていません。
もちろん、私は調査を行いましたが、SSIS がトリガーする可能性のある脆弱性 (たとえば、アクセス データベース内のスクリプト?) を導入していますか?
前もって感謝します。
私はDavidに同意します（「決して」という言葉を使用することは常に危険ですが！）。考慮すべきもう1つのことは、アップロードする前にデータベースを圧縮する人に、各ユーザーに固有のパスワードを使用してzipファイルに暗号化を適用させることです。
実際の暗号化は、通信がハッキングされた場合に役立ちますが、必ずしも特に強力である必要はありません。重要なのは、Accessのアップロードを開始した人物を識別するのに役立つということです。SSISプロセスが既知の各パスワードで順番に開こうとし、すべてのパスワードで失敗した場合、パッケージは許可されていない人物によってシステムに導入されたと見なされる可能性があるため、疑わしいと考えられます。
これは、悪意のあるコードを防ぐためではなく、悪意のあるデータがシステムに入力されるのを防ぐためです。
hth
マイク
SSIS は ODBC または OLEDB を使用して Access/Jet/ACE データベース内のデータにアクセスする可能性が高いため、コードを実行するものは何もありません。ODBC と OLEDB は、データと実行される可能性のあるすべての危険な機能以外は何も知りません。 SQL ステートメントはブロックされます。
したがって、Access がインストールされていなければ、実際の危険はありません。存在することが懸念される場合は、ファイルを開く前に DAO でファイルを処理し、QueryDefs コレクションと Modules ドキュメント コレクション内のすべてを削除できます。または、データ テーブルのみをインポートするバッファー データベースを使用して、それを SSIS に渡すこともできます。
しかし、SSIS が最初からデータ テーブル以外を見ているとは思えません。
ところで、Access を介して伝播されたウイルスやエクスプロイトは一度もなかったので、Access の脆弱性に関する懸念は非常に誇張されています (その結果、ブロックされたマクロ、サンドボックス モード、および A2007 以降、.信頼できる場所を定義する必要があります)。