你把你的数据库修改登录时只能用用户名和密码登录，不允许windows登录，然后为他创建一个用户，这个用户赋予的权限你自己选，你想让他看什么就给他权限。不想就别给他赋权限即可。
创新互联公司2013年开创至今，先为砀山等服务建站，砀山等地企业，进行企业商务咨询服务。为砀山企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
比较简单的做法是数据在存入数据库之前用c#进行加密，然后再存入数据库，读取数据之后，用相应的解密方法对数据进行解密。
但是，如果你一定要在存储过程中加密的话，可以使用c#创建好对应的加密解密方法，然后生成一个加解密的类库dll，在sqlserver中引入该dll中的加密方法进行加密（Sqlserver调用dll的方法sqlserver调用dll），程序中可以直接调用该dll中的解密方法，也可以把解密方法直接写在程序中。
到了SQL Server2005，引入了列级加密。使得加密可以对特定列执行，这个过程涉及4对加密和解密的内置函数
SQL Server 2008时代，则引入的了透明数据加密（TDE），所谓的透明数据加密，就是加密在数据库中进行，但从程序的角度来看就好像没有加密一样，和列级加密不同的是，TDE加密的级别是整个数据库。使用TDE加密的数据库文件或备份在另一个没有证书的实例上是不能附加或恢复的。
就这一点 透明数据加密比列级加密要好用的多。
Microsoft Network Monitor
这是微软提供的网络抓包工具
虽然它是微软提供的，但所有的协议parser解析代码全部都是开源的，采用其支持的特有脚本语言编写，易理解、易扩展；
它自带协议parser比较全面，同时有一个开源社区提供持续支持；
另外，它也提供API帮助我们开发自己的网络抓包、协议分析工具。
针对TDS协议解析需求：
Network Monitor自带TDS协议解析器和UI比较友好
Network Monitor自带TDS协议解析器在解析和结果展示方面更全面，以下是一个画面片段，显示了一个SQL Batch包。
先了解一下SQLSERVER的加密阶段
一共有两个阶段
在认证阶段，SQLSERVER会使用自生成的自签名证书，加密客户端发过来的登陆用户名和密码
在数据传输阶段，如果不使用证书，那么数据是使用明文在网络上进行传送的
大家可以看一下这篇文章：
SQL Server 连接加密 (1) -- SQL Server connection encyption
网上有很多制作证书的教程，但是制作证书都比较麻烦，客户端和服务器端都要弄很多东西。
详细制作证书的过程可以参考园子里的这篇文章：
在SQL Server 2005 中开启SSL(图文结合)
当然这篇文章不是讲解这个network monitor抓包工具的，所以轻轻带过就算了
那么，不制作证书怎么加密传输的数据啊？？？？
答案就是：同样使用在认证阶段的自生成的自签名证书
详细步骤：
步骤1：在SQLSERVER服务器端这边设置强行加密
步骤2：重启SQLSERVER，只有重启SQLSERVER设置才能生效
步骤3：打开network monitor，新建一个capture
步骤4：启动capture，开始捕获
步骤5：在客户端这边连上服务器端的SQLSERVER，然后你会在network monitor里的看到SSMS这个进程已经出现在Network Conversations窗口
步骤6：选中他，你会在Frame Summary窗口看到帧信息
步骤7：如果你在服务器端开启了“强行加密”，那么收到的数据包都会是加密的
大家在Protocol Name这一栏看到的是TLS协议，而不会是TDS协议
步骤8：查看帧数据
步骤9：如果没有加密的明文数据，network monitor就能够查看出来，并且Protocol Name这一栏显示的是TDS协议，因为数据包并没有使用TLS协议进行封装
TIPS：当关闭了SSMS的查询窗口之后，连接还是存在的
很多人会问，关闭了连接，怎么连接还存在，客户端为什么还会跟服务器端进行通信？？？？？
实际上，这个是客户端的连接池机制，客户端不断发送keep alive数据包给服务器，下次有同样的连接进行重用了，不需要再进行三次握手o(∩_∩)o
总结
本人介绍了不使用制作证书的方式来对传输的数据进行加密的方法，实际上设置客户端而不设置服务器端也是可以的
不过设置客户端比较麻烦，还需要在连接字符串里加上encrypt属性设置为Yes
设置服务器端和设置客户端的加密的区别
服务器端：所有的连接都是加密的
客户端：只是设置了加密的那个连接是加密的，其他没有设置加密的连接依然是明文传输数据
当然，使用SQLSERVER自生成的证书安全性是不及自己制作的证书的安全性高！！
相关连接：
加密与 SQL Server 的连接
使用自签名证书加密的 SSL 连接不提供强安全性。它们容易在传输中途受到攻击。在生产环境中或在连接到 Internet 的服务器上，不应依赖使用自签名证书的 SSL。
始终要对客户端应用程序与 SQL Server
连接时传输的凭据（在登录数据包中）进行加密。SQL Server
将使用可信证书颁发机构颁发的证书（如果可用）。如果未安装可信证书，则在启动实例时 SQL Server
将生成自签名证书，并使用自签名证书对凭据进行加密。自签名证书有助于提高安全性，但它不提供针对通过服务器进行的身份欺骗的保护。如果使用自签名证书，
并且 ForceEncryption 选项的值设置为“是”，则将使用自签名证书对通过网络在 SQL Server
和客户端应用程序之间传输的所有数据进行加密
