Share via

Security Considerations (Synchronization Services)

  • Article

To help secure applications that are based on Synchronization 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 2005 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. Synchronization Services does not provide encryption for connections. Encryption is available at the transport level with several technologies. These include the following industry standard technologies: 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 database that you are using.
  • Use stored procedures instead of inline SQL to query server databases. Stored procedures help to secure an application in at least two 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.
  • 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 server-side assemblies and client-side assemblies in N-tier architectures. In N-tier scenarios, server-side assemblies and client-side assemblies should build trust between each other. The mechanism to build the trust relationship is outside the scope of the Synchronization Services API and must be handled by your application.
  • Explicitly set the ClientId property in the client application if you can. If the property is not set, an ID is assigned by Synchronization 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.
  • Do not rely on filtering for security. The ability to filter data from the server based on a client or user ID is not a security feature. In other words, this approach cannot be used to prevent one client from reading data that belongs to another client. This type of filtering is useful only for partitioning data and reducing the amount of data that is brought down the client database.

See Also

Concepts

Considerations for Application Design and Deployment (Synchronization Services)