您的公司应该聘请安全专家来帮助该项目，并重新开始。
我知道不回答您直接的技术问题可能看起来令人沮丧，但我可以向您保证，鉴于当前的发展轨迹，StackExchange 答案中可以合理提供的技术细节不会对您或您的组织产生重大影响项目。
到目前为止，项目设计过程似乎是：
- 您的组织已确定现有功能当前无法满足的业务需求，并且您已决定构建基于云的 CRM 来满足该需求。
- 您的经理已决定客户端加密是一项要求，并将设计此功能的责任委托给您（非安全专家）。
- 您已经研究了许多用于实现客户端加密的技术。
虽然优先考虑安全性很好，但该组织目前对该项目的方法存在许多问题。
首先，也是最关键的一点，每个人都走得太远、太快了。您已经在查看支持实现细节的软件堆栈，但是像这样的系统的安全性是基于架构和设计的，而不是您使用的数据库或 Web 存储解决方案。在这方面缺乏规划几乎总是会让您陷入系统无法实现其业务目标和安全要求的情况，并且试图弥补差距会给您带来大量的技术债务。
已选择基于云的定制 CRM 作为业务问题的解决方案。但是，尚不清楚是否有足够的安全分析来做出这一决定。您的公司应该问“我们如何以安全的方式实现 X？”，而不是“我们需要 X => 我们可以用 Y => 来做到这一点，而这可以用 Z => 我们如何做 Z？”。似乎没有威胁模型，似乎任何安全决策都不是由该威胁模型驱动的。
你已经意识到你的老板要求你完成的任务超出了你目前的专业领域，你正在寻求帮助。这是一件好事——你已经发现了一个知识空白，并且你正在寻找填补它。不幸的是，当涉及到这样的项目时，仅仅获得个人技术细节的帮助是不够的。这些系统有很多隐藏的微妙之处和陷阱，驾驭这些既需要经验，也需要深厚的技术知识。这种类型的项目安全支持与开发软件完全不同。
我还担心您的组织在没有先进行可行性研究以确定您是否拥有内部必备知识和经验的情况下就采用了这种方法。围绕不受信任的服务器模型构建安全的多方文档交换解决方案是一项复杂的工作，需要深入了解安全性和密码学。计划器和日历等交互功能更加复杂。最小的细节可以隐藏破坏整个安全模型的脚枪，有时在不完全重新设计系统的情况下无法解决（这显然是不可行的）。我已经为这些类型的系统进行了设计，并且我已经评估了更多，我认为它们是最难做好的系统类型之一。
需要明确的是：这些批评并非意在消极或指责。在我的职业生涯中，我曾与数百个组织合作过数千个项目，这种类型的项目方法并不罕见。当你没有人引导你朝着正确的方向前进时，你所能做的就是勇往直前，糊里糊涂，努力把事情做好。这没有什么可耻的。但贯穿所有这些活动的一个共同点是，那些让安全专家在尽可能早的阶段帮助指导他们的公司——当他们只是决定他们可能需要建立一个系统——他们最终不会得到一份充满严重严重性问题的渗透测试报告，也不会最终花费数千美元对一个只有一半的系统进行重新测试和额外的安全控制做他们想做的事。从纯粹的财务角度来看：在项目开始时花钱进行安全咨询可以为您节省更多的后期持续成本。
我很同情你所处的位置。我一直是一名开发人员，我当然没有做出重大项目的决定。如果你把这个答案告诉你的老板和项目负责人/利益相关者（嗨！），我希望它能引导他们朝着正确的方向前进，并在此过程中为你和公司节省一些麻烦。