Bookafy的安全和隐私

安全常见问题 

在过去5年中，是否发生过任何重大的安全漏洞或事件？

没有。

特权账户和通用账户的访问是否受到严格控制并定期审查，至少

每年？

是的。

正在收集关于用户的什么数据？ 

该软件收集有关账户所有者和最终客户的数据。 这两套数据都是基于账户所有者和最终客户提供的数据。 我们不收集终端用户或账户所有者自愿提供的数据之外的任何数据。 

账户所有者可以创建文本字段，在预订时收集不同的数据点，但客户完全知道正在收集的数据，因为最终用户将把数据输入字段。 最终用户或账户所有者可以在任何时候通过发送电子邮件至 data@bookafy.com 要求删除数据。 

该应用程序使用这些数据的目的是什么？

应用程序的数据只用于最终客户所签署的交易。 如果使用第三方应用程序以SSO方式登录，如Facebook或Google，我们只使用该连接来访问账户。 我们不使用账户中的数据，如联系人、事件、电子邮件信息，我们也不代表您在您的账户中发布或参与任何活动。 它只用于登录。 

用户有哪些删除数据的权利，用户如何要求删除数据？ 

我们使用从账户所有者（我们的客户）那里收集的数据，向账户所有者提供更好的体验。 这包括任何AO被卡住的地方，多次访问的地方，可能有问题的地方，或者是一个错误。 我们利用这些数据，在正确的时间与我们的客户（账户所有者）进行沟通，提供正确的信息。 

对于最终用户，我们客户的客户……我们只为与账户所有者的交易（预订）而使用这些数据。 我们不会向这些客户推销，或以任何其他方式使用他们的数据。 他们的数据不会被出售或借用……它留在我们的系统中。 

在AO和终端客户的情况下，他们的数据可以在任何时候被删除。 AO可以发电子邮件到data@bookafy.com，要求删除他们的账户和数据。 最终客户可以要求AO删除他们的数据。 

是否禁止员工使用共享用户账户？ 客户怎么办？

员工有自己的专用账户。 客户也有自己的专用账户，只能访问他们的数据。

您的密码构造是否需要多种强度要求，即强密码并利用字母、数字和特殊字符的随机序列？

在基本的密码管理层面，我们要求密码至少有6个字符。 OWASP和NIST SP 800-63-3密码政策选项可能在未来一年内出现。

网络边界是否有带入口和出口过滤的防火墙保护？

是的。 所有防火墙和负载平衡设施都由Azure和亚马逊AWS提供。

面向公众的服务器是否在一个定义明确的非军事区（DMZ）？

是的，这是从Azure的默认基础设施分区中继承下来的，Bookafy的区域服务器分布在世界各地。 

内部网络分段是否用于进一步隔离敏感的生产资源，如PCI数据？

PCI数据不被存储，因为它只是由Bookafy从第三方供应商（如Stripe和Authorize.net）处获得的框架。 Bookafy不收集数据或存储数据。 

网络入侵检测或预防是否得到实施和监控？

广泛的监测工具，辅之以Azure提供的通知和警报，一直在不断地进行。 这包括入侵检测和网络访问的电子邮件确认。

所有的台式机是否使用定期更新的病毒、蠕虫、间谍软件和恶意代码软件进行保护？

是的。

服务器是否使用行业加固做法进行保护？ 这些做法是否有记录？

定期利用安全服务来提供系统安全审计。 

所有操作系统、网络设备和应用程序是否有积极的供应商补丁管理？

是的。 这是由Azure通过其服务自动提供的。

所有的生产系统错误和安全事件都被记录和保存了吗？

日志至少保存1个月，有些会保存到6个月，这取决于严重程度和需要采取的行动。

是否定期审查安全事件和日志数据？

是的。 每天、每周和每月都会对日志进行审查–取决于日志事件的性质。

是否有成文的隐私计划，并有保障措施以确保保护客户的机密信息？

是的。

如果发生任何隐私泄露，是否有一个程序来通知客户？

是的。

你是否存储、处理、传送（即 “处理”）个人可识别信息（PII）？

是的。

PII存储在哪个国家或哪些国家？

我们的大部分PII数据都储存在美国。 然而，我们能够在一个特定的区域中心为我们的企业客户存储账户数据。 例子。 澳大利亚的组织可以选择将其数据存储在我们的堪培拉Azure地点。 或者欧洲国家可以存储在欧洲的数据中心。 

系统日志是否受到保护，不被篡改和破坏？

这是由Azure提供的，并在Dropbox云存储上进行了备份。

边界和VLAN的入口点是否受到入侵保护和检测设备的保护，在受到攻击时提供警报？

是的。 这些服务包括在我们的Azure防火墙中，它可以防止入侵并向我们的开发团队发送自动警报。 

日志和事件是否与提供正在进行的攻击警告的工具相关联？

是的，我们的安全服务包括对攻击的实时记录和警报。 

在解决方案中，数据是如何与其他客户隔离的，包括网络、前端、后端存储和备份？

通过在所有数据库记录上使用必要的持久性租户标识符，每个客户账户都与其他客户逻辑地分开。

此外，所有的应用程序代码在所有的操作中都需要这个租户标识符–包括读和写。 一个自动化的测试制度也已经到位，以保护代码的变化不受回归和可能的跨租户数据污染的影响。

租户标识符被 “硬连接 “到每个用户账户，并通过数据库查询的固定 “WHERE “条款和文件访问的同等措施在逻辑上强制执行。 平台用户不能改变或以其他方式解除他们的会话或账户与该租户标识符的联系。 因此，在逻辑上不存在一个用户在不同租户标识符下拥有登录授权的可能性。 即使他们试图使用不同租户的ID访问页面，系统也会拒绝该请求，因为用户账户没有注册到所请求的租户ID。

你有一个事件响应计划吗？

是的，保持一份 “活的文件”，其中概述了灾难和事件的反应。

核对表、联系方式以及了解和应对事件的关键系统设施。

实施何种程度的网络保护？

我们利用Azures Web应用网关（负载平衡器）和下一代防火墙来保护我们在Azure云上运行的虚拟机网络。 

该平台是否提供服务质量（QOS）性能测量报告（资源利用率、吞吐量、可用性等）？

除了根据我们在status.pingdom.com上的状态页面提供的可用性和响应时间外，这些指标不会提供给客户。

灾难恢复计划是否至少每年测试一次？

是的，每年进行恢复检查和测试。

系统的恢复时间目标（RTO）和恢复点目标（RPO）是什么？

RTO是4小时，RPO是1小时。

你们是否为个人客户提供备份和恢复计划？

所有方面都是多租户，所以备份是在整个客户群中进行的。 完整的文件备份每24小时运行一次，并得益于Azure数据库每5分钟一次的时间点备份。 备份存储在Dropbox云以及冗余的Azure虚拟机上。 

备份的最长保留时间是多久？

数据库的时间点备份保留30天，一般文件备份至少保留90天。

数据恢复的预期周转时间是什么？

在任何非灾害情况下，任何客户的恢复都必须向我们申请和安排。 周转时间在1至2个工作日之间。 

能否在不影响整个平台的情况下恢复单个实体账户？

如果客户需要修复一个特定的记录或文物，可以通过每个请求的基础上在线进行，这是收费的工作。 对平台或客户账户没有影响。

是否提供高可用性 – i. e. 当一个服务器实例变得不可用时，另一个是否会变得可用？

多个服务器实例通过Azure的虚拟机在所有系统层运行，由Web应用网关处理负载平衡。 数据中心内服务器实例的故障由Azure WAG处理，有问题的实例会被回收和/或移除并被新的实例取代。

数据是否存储在另一个地方（数据中心）并可用，以满足灾难恢复要求？

是的。所有数据都被复制到第二个数据中心，该中心因地理位置不同而不同，同时也有备份数据存储在Dropbox云存储上。.

故障转移过程是一个主动/主动、自动切换的过程吗？

主数据中心内的服务器实例发生故障时，由Azure WAG负载平衡器处理，问题实例会被回收和/或删除，并由新实例取代。

如果整个数据中心发生严重故障，那么切换到第二中心是一个手动过程，因为我们需要首先对问题进行全面评估，以确保没有简单的变通方法来保持现有主中心的可用性。 如果确定需要转移到二级中心，那么将手动启动切换，以满足目标恢复目标。