我们是一个只有less数员工的小公司。 我们的非技术COO要求我们设置一个生产数据库的副本，供他使用像Chartio这样的服务，因为我们（很差的）pipe理仪表板不能满足他的需求。
COO希望使用朋友（承包商）来帮助将Chartio服务与我们的数据库集成。
我们所有的密码都是encryption的，但是电子邮件和名字都以明文forms存储。 我们通过第三方提供商处理付款处理，因此我们不存储除交易总额以外的任何敏感财务信息。
这是一个坏主意，还是我过于谨慎？
PS：我们会自己build立数据库服务器，所以我们可以控制防火墙等等。
最后，公司董事会代表公司做出“全景”的决定，所以我不认为我会准备好做一些仅仅是不明智的事情（尽pipe我不会做一些我认为是违法的事 – 在许多司法pipe辖区，“遵守上级命令”不会保护你免受违法的后果）。
如果是我，我会希望他用书面的方式指示我把这份文本给他，最好在那个指令中确认他知道我对那个离开公司的数据库的担忧，但却指示着我继续下去。
logging你在做什么，并创build副本。 如果你不暴露非常机密的数据（电子邮件不完全是），那么没有真正的伤害。 但是，文件！ 这样，如果有事情发生（在这里玩世不恭），你被覆盖。
主观的问题，但我说不好的主意 ，一个主要原因：你正在修复症状，而不是问题。 当Chartio不再满足他的需求时会发生什么？ 然后是开放的下一个大的事情，另一个数据库的副本。
真正的问题是数据库报告解决scheme。 你没有提到你使用的是什么DB，但是假设像MySQL那样支付图表types会挫败我使用免费数据库的目的。 如果你支付Chartio，那么你可能还要支付MSSQL，并有很好的报告。 我敢肯定，有MySQL的报告有适当的免费解决scheme，虽然我不知道一个副手。
我同意书面答复，并expression了担忧（ 尤其是如果你是IT安全人员），但我有一种感觉，这将为首席运营官（也可能是其他大型假发）口授IT策略开创一个先例。 只是一个想法，其预算是这Chartio出来….？
更新
最后，设置生产数据库的“副本”实际上不是最好的，因为它是一个副本，永远不会是实时的（我认为你的意思是一个文字副本而不是集群/复制）。