Share via


Security Considerations (Sync Services)

To help secure applications that are based on Sync Services, we recommend that you take the following steps. For more information about database security, see SQL Server Compact 3.5 Books Online and SQL Server Books Online.

  • Use the principle of least permission. Do not grant more permissions than are required to perform a specific task. For example, do not grant INSERT permissions for server database tables that are involved in download-only synchronization.

  • Configure servers and server databases to expose the least surface area for attack. For example, if you use an Internet Information Services (IIS) server as part of an N-tier architecture, do not enable the file transfer protocol (FTP) service unless it is required by another application that uses the server.

  • Encrypt or password-protect sensitive data on disk and in transit. Sync Services does not provide encryption for connections. Encryption is available at the transport level with several technologies. These include the following industry standard technologies: Windows Communication Foundation (WCF), Virtual Private Networks (VPN), Secure Sockets Layer (SSL), and Internet Protocol security (IPsec). We recommend that you use one of these encryption methods for the connections that are made during synchronization. For more information about encryption, see the documentation for Windows and SQL Server Compact 3.5, and the documentation for the server or peer database that you are using.

  • Use stored procedures instead of inline SQL to query server databases. Stored procedures help to secure an application in the following ways:

    • By using stored-procedures, administrators can define a well-known set of entry points to the database. Users can be given access to stored procedures and not to the underlying tables.

    • The use of stored procedures also encourages the use of parameters instead of dynamically built queries. This makes it more difficult to perform SQL injection attacks.

    • If an application is compromised, the data access logic is not necessarily compromised.

  • Validate the data sent during synchronization. Use the events that fire during synchronization to validate changes before you apply those changes on the destination database. For more information about events, see How to: Work with Events and Program Business Logic.

  • Establish trust between local assemblies and remote assemblies in N-tier architectures. In N-tier scenarios, local assemblies and remote assemblies should build trust between each other. The mechanism to build the trust relationship is outside the scope of the Sync Services API and must be handled by your application.

  • If you use tracing, be aware that trace files can include information about server and client computers, application data, and logins. (Passwords are not written to the trace file.) If verbose tracing is enabled, each changed row from the database is written to the trace file. Help protect the trace file by using the appropriate access control lists. For more information about tracing, see How to: Trace the Synchronization Process.

  • For client and server synchronization, explicitly set the ClientId property in the client application if you can. If the property is not set, an ID is assigned by Sync Services. In this case, the client application must be able to access the following registry hive on the server: HK_CURRENT_USER\Software\Microsoft\Microsoft SQL Server Compact Edition\v3.5. Accessing the registry hive requires administrator rights. This is not recommended.

  • Do not rely on filtering for security. The ability to filter data based on a client or user ID is not a security feature. In other words, this approach cannot be used to prevent one client or peer from reading data that belongs to another client or peer. This type of filtering is useful only for partitioning data and reducing the amount of data that is synchronized.

See Also

Concepts

Considerations for Application Design and Deployment (Sync Services)