HTTPS 和加密数据库在共享主机中真的安全吗？
我阅读了有关 HTTP over SSL 的所有帖子。到目前为止，我知道如何以 Web 形式安全地获取数据。但我错过了恢复部分并以相同的方式保留数据。 我需要在我的网站中提供一个表格来收集客户的敏感数据（也可能是用于预订的信用卡号码，但不需要信用卡授权过程），然后以安全的方式保存和读取该数据。
然后，对于基本的安全 Web 应用程序，我需要：
a) 具有 SSL 域验证 (DV) 证书的网站（我没有固定的 IP 地址。我使用基本的共享或“虚拟”托管服务）。
b) 开发一个简单的PHP & MySQL 应用程序收集客户的敏感数据，将所有应用程序 PHP 文件放在 SSL 安全文件夹中。
c) 所有收集到的数据将存储在服务器MySQL数据库中。
这是我的消息中的问题部分：
1）如果我稍后使用 phpmyadmin 输入通过常规托管服务（HTTP）查看数据库，这不是不安全吗？
2) 托管管理员呢？如果我在数据库中使用纯文本，他们还可以读取所有敏感数据。但是服务器上数据的加密方法（不仅是通过 SSL 传输）是否足够？加密编码/解码方法不是真的可以被托管管理员拦截吗？ （考虑一下：该方法位于同一服务器的应用程序内部）。 我无法支付自己服务器的便利性和安全性。
3）考虑到这些事情，并假设它们是真的......如果我选择数据库加密真的很重要吗？
可能是我错过了一些东西或者我误解了一些问题。
非常感谢您的帮助和耐心。
I read all posts on HTTP over SSL. So far, I know how to get the data securely in a Web form. But I miss the part of recover and keep the data in the same way.
I need in my Website a form to collect sensible data from customers (may be also credit cards numbers for booking, but no credit card authorization process is required) and later keep and read that data in a secure way.
Then, for a basic secure Web application I need:
a) Web site with SSL Domain Validated (DV) Certificate (I don't have fixed IP address. I use basic shared or "virtual" hosting service).
b) Develop a simple PHP & MySQL application that collect sensible data of customers, putting all the app PHP files on the SSL secure folder.
c) All the collected data is gonna be stored in the server MySQL database.
This is the questions part of my message:
1) If I enter later using phpmyadmin to take look at the database over regular hoster services (HTTP), isn't this insecure??
2) What about the hosting administrators? They could also read all sensible data if I use plain text in the database. But encryption methods for data on the server (not only in transmission over SSL) could be enough? Isn't true that the encryption encoding/decoding method could be intercepted by the hosting administrators?? (consider this: the method is inside the application in the same server).
I can't pay the convenience and security of an own server.
3) Considering those things, and assuming that they are true... really matter if I go for a database encryption?
May be I missed something or I misinterpreting some issue.
Thanks a lot for your help and patience.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这些共享托管计划并不能真正胜任收集信用卡号的工作 - 您是使用支付网关进行投注，而不是自己存储它们。
请参阅相关规定：PCI
These shared hosting plans are not really up to the job of collecting credit card numbers - you are betting using a payment gateway and not storing them yourself.
See some regulations on this: PCI
我希望您没有存储信用卡或其他敏感数据，特别是在您所在司法管辖区的隐私法涵盖的情况下。将此类内容存储在共享服务器上可能会让您被起诉。如果不出意外，以这种方式存储信用卡数据将侵犯您的商家帐户 - 如果他们得到风声，您将无法使用 Visa 和 MasterCard。
I hope you're not storing credit card or other sensitive data, particularly if covered by privacy laws in your jurisdiction. Storing that sort of stuff on a shared server will probably get you sued. If nothing else, storage of credit card data in this manner will be a violation of your merchant account - if they get wind of it, Visa and MasterCard will become unavailable to you.
1) 当然，通过 HTTP 使用 phpmyadmin 查看数据是不安全的。
关于2），如果您没有物理安全性，那么您就无法拥有任何安全性（也许除了存储在托管站点之外加密和解密的加密数据之外）。
由于您的托管公司可以访问计算机，因此他们可以读取您的所有数据。
话虽如此，根据我的经验，托管提供商不会这样做，并会尽力保证您的数据安全（因为那是他们的业务），就像银行的业务就是尽力保证您的数据安全一样。为您提供金钱并保护它而不是拿走它。
3) 仅在保留备份的情况下才进行数据库加密。对于运行实时版本，它提供的安全性几乎没有增加（如果有的话），并且使事情变得更加麻烦。
1) Seeing the data with phpmyadmin over HTTP is insecure, of course.
Regarding 2), if you don't have physical security, then you can't have any security (perhaps with the exception of storing encrypted data which you encrypt and decrypt outside the hosting site).
As your hosting company has access to the computer, they can read all your data.
Having said that, in my experience hosting providers will not do that and try to keep your data safe (because that is their business), pretty much in the same way banks' business is to try to keep your money for you and safeguard it and not taking it.
3) Go for database encryption only if you keep backups. For running the live version it provides little more security (if at all) and makes things more cumbersome.
是的。
他们可以。
并非如此，但这仍然是一个好主意。有人可以获取您的数据库，但无法获取 PHP 源代码。那么数据库中的加密将是一件好事。
你是对的。唯一可以确定的方法是运行您自己的服务器。您还应该了解支付卡行业数据安全标准。
It is.
They can.
Not really but it could still be a good idea. Someone could get hold of your database and not the PHP source code. Then encryption in the database would be a good thing.
You are correct. The only way to be sure is to run your own server. Also you should know about the Payment Card Industry Data Security Standard.
我认为 bobince 是完全正确的。公钥加密可以帮助您，但请记住，您会失去使用 PHPMyAdmin 查看数据的舒适感 - 您会在侧面的某个地方看到需要解密的垃圾。请参阅 http://www.php.net/openssl 了解有关 PHP 和公钥加密的更多信息。
I think that bobince is totally correct. Public key crypto can help you but keep in mind that you loose comfort of using PHPMyAdmin to view the data - you will see garbage that will need to be decrypted somewhere on the side. See http://www.php.net/openssl to learn more about PHP and public key crypto.
正如您怀疑的那样，完全在服务器上进行加密/解密过程只是混淆，本身并不安全。它可以在部分妥协的情况下提供帮助，即攻击者获得对数据库的读取访问权限（通常通过 SQL 注入漏洞），但无法读取站点脚本或运行任意代码。
如果您只需要写出服务器不需要读回的敏感数据（规范的信用卡号），则可以使用公钥加密来实现。使用公钥加密数据，然后仅在具有相应私钥的已知安全计算机上读取数据。在脚本可读的情况下，这可以保护过去的数据，并且在攻击者获得对脚本的写访问权限的情况下，他们至少只会泄露新的传入数据，而不是旧的数据。希望这能让您有时间检测入侵并进行重建。
是的。但随后主机可以物理访问该机器，因此可以在其上安装 rootkit，拦截 web 应用程序从第一天开始执行的所有操作（如果他们真的愿意）。没有办法信任您的主机，因此请选择一个信誉良好的主机，并且不要在共享服务器上运行敏感系统。
Having an encryption/decryption process entirely on the server is, as you suspect, mere obfuscation and not secure in itself. It can help in cases of a partial compromise, where an attacker gains read access to the database (typically through an SQL injection hole) but no ability to read the site scripts or run arbitrary code.
If you only need to write out sensitive data (canonically credit card numbers) that the server doesn't need to be able to read back in, you can do that with public key cryptography. Encrypt the data with your public key, then read it only on a known-secure machine that has the corresponding private key. This protects past data in the case of a greater compromise where the scripts are readable, and in the case where an attacker gains write-access to the scripts, they at least only get new incoming data leaked, and not the old stuff. Hopefully that would give you time to detect the intrusion and rebuild.
Yes. But then the hosts have physical access to the machine, so could bang a rootkit on it that intercepted everything the webapp was doing on the fly from day one, if they really wanted. There's no way around trusting your host, so pick a reputable one and don't run sensitive systems on shared servers.