ssae 16 中的哪里描述了数据中心或 SaaS 提供商的具体操作程序？哪里描述了谁可以访问生产硬件的限制？这个文档是公开的吗？SSAE16.org 涉及很多通用的圈子。我看到一个购买书籍的链接，但我想确保它是正确的材料（http://www.cpa2biz.com/search/results.jsp?N=4294967176+4294966607）
背景：我知道有很多帖子与“吸血鬼和狼人”的争论有关，我也熟悉 DevOps 运动，但那场争论不是我的问题。一个症结是审计（特别是 SSAE 16）。审计的常见概念是“职责分离”，最终会限制开发人员对生产系统的访问。
过去，审计基本上验证了你“言出必行”，但许多人似乎暗示 SSAE 16 超越了标准化审计，实际上为数据中心和服务提供商添加了具体断言。如果我要推动 DevOps 之类的事情，我需要确保能够充分解决审计问题。
我意识到这并不是专门针对计算机系统，但我认为它绝对属于“专业系统和网络管理员”的范畴。
短暂性脑缺血发作
答案1
经过一番思考后，我认为它与“系统管理员相关”的程度足以保证一个实际的答案——系统管理员很高兴接触各种行业审计标准（SAS / SSAE，PCI，ISO和无数其他标准），而关于如何处理审计的好的一般性答案是我们缺乏的，所以这里是我尝试做的一个。
TL;DR 版本：
- 让自己适用标准的副本
- 读标准。
- 理解标准。
- 确保贵公司的政策和程序符合要求。
- 确保贵公司关注其政策和程序。
- 享受轻松无忧的审计吧。
SSAE 16 特有的材料将像这样偏移。
请注意，SSAE 16 与其替代的 SAS 70 声明一样，并不是真正的“标准” - 它是一个陈述AICPA 就如何进行审计以及如何呈现结果制定了标准。SSAE
16 审计本身仍然是一种“公司按照其程序、合同等规定行事”的审计。它经常被当作“审计恶魔”来使用，但它其实并没有那么可怕，而且本身的要求很少。
什么是无论如何都要进行审计？
维基百科对审计有很好的定义：对个人、组织、系统、流程、企业、项目或产品的评估。
在我们最常涉及的环境中，审计旨在确保组织的流程和程序符合某些控制目标 - 例如确保只有授权用户才能更改防火墙的配置。
听起来很简单...那么他们要看什么呢？
如果审计正确进行，审计中涵盖的所有内容都将在您所接受审计的标准中详细说明。如果您查看标准，您就会知道要审查什么，并且您可以进行自己的内部审查和审计，以确保在进行外部（“认证”）审计之前您符合规定。
就 SSAE 16 而言，《鉴证业务准则声明》（SSAE）由美国注册会计师协会。它是您可以从他们那里获得的几种免费标准文档之一。
这一切听起来都很棒，但是为什么 IT 会参与其中呢？
说出 IT 不涉及的业务方面。
许多（如果不是大多数）实施的控制措施都有一些技术基础（例如“用户使用用户名和密码登录”），最终由技术人员负责。
好的，我需要为审计做哪些准备？
一般来说，任何审计都需要做两件事准备：
- 您正在接受审计的标准文件。
这实际上是任何审计的零项：审计员必须核实贵公司是否拥有标准文件的最新版本。审计员
有时会忽略这一点，但如果您试图遵守您未读过且无法参考的标准，这对您不利。 - 合理数量的常识。
你需要阅读标准文档，然后- 将标准的每项要求映射到现有流程、程序或控制；或
- 创建新的流程、程序或控制来满足要求。
这听起来还是不太可怕。为什么人们讨厌审计？
人们不喜欢审计有两个常见原因（除了审计本身固有的生产力损失之外）：准备不充分或审计员不好。
准备不充分——或者“如何确保糟糕的审计体验。”
许多人都有过审计失败的经历 - “本来应该一天就搞定，结果他们却拖了我们两个星期！”我没有统计数据支持我的观点，但据传闻，我听到的大多数此类故事都可以归因于被审计组织准备不充分。
无论是由于无知、懒惰还是资源限制，组织都未能达到其定义的一个或多个控制目标（或标准要求），审计员通过打组织头并说他们搞砸了来履行职责。
例如，如果某项标准要求您防止未经授权的用户修改生产系统，那么实现此目的的一种方法是为所有管理员提供共享的用户名/密码，只有管理团队知道。
这当然符合该要求，尽管任何系统管理员都会说这很荒谬，但如果您很懒或很着急，您可能会实施此解决方案。
如果您进一步阅读该标准，您可能会发现另一条款，例如“必须记录生产机器上的配置更改，包括更改的日期、时间和人员”——突然间您的共享密码方案不再起作用：您需要单独可追踪的身份识别和身份验证，如果您阅读过该标准（或者仔细考虑过要求并使用了我之前提到的常识），您就会知道这一点。
你会看到一个审计师指出准备工作不充分的例子SSAE 16 第 801 节附录 B，摘自一份样本审计报告，内容如下：
The accompanying description states on page [mn] that XYZ Service Organization uses operator identification numbers and passwords to prevent unauthorized access to the system. Based on inquiries of staff personnel and observation of activities, we have determined that operator identification numbers and passwords are employed in applications A and B but are not required to access the system in applications C and D.
糟糕的审计员-或“我不知道为什么，我只是被告知你需要这样做X！”
另一个极端的情况也发生了——审计员通常不是他们审计的所有领域的专家。他们几乎肯定熟悉标准（如果他们不熟悉，请要求另一位审计员！），但标准的具体应用可能超出了他们的专业范围。
审计员不必是系统管理员就可以知道控制目标Usernames and passwords are employed as an access control mechanism for XYZ Application——他们可以观察几个人使用系统并验证每个人是否输入了用户名和密码。
糟糕的审计员不理解实现控制目标的方法有很多种（例如，使用智能卡而不是用户名和密码登录），或者更糟糕的是审计人员根本不理解他们所审计的标准背后的原因通常
，您所能做的就是不同意审计员的意见（将问题提交给他们的老板，要么提供证据证明您满足审计员声称您没有满足的要求，要么提供证据表明审计员的要求超出范围或本身违反了您应遵守的标准）。
审计“失败”
有几种方法会导致审计“失败”，有些方法比其他方法更好。
这种情况很少发生，你也不应该指望它。每次审计都会发现一些问题。这些问题有很多不同的名称——“审计例外”、“不符合说明”和“违规”是相当常见的——但仅仅因为有负面发现并不总是意味着你“未通过”审计。
认证审核通常针对具有特定性能要求的标准进行（也许最著名的例子是 ISO 9000 系列质量管理标准）。审核完成后，审核团队会向认证机构提出建议，认证（或不认证，或取消认证）组织“符合”给定标准。
性能上的轻微缺陷可能不会妨碍认证。
例如，ISO 9001 要求公司建立定期质量数据审查。如果一家公司声称每 30 天对其生产线进行一次质量审查，但实际上他们每月第一天进行一次，那么他们技术上不符合其程序，因此最严格的应用他们无法获得认证。
在这种情况下，通常会发生的情况是，审核员发出一份不符合通知，并建议认证“等待对所有不符合通知的可接受纠正措施”。然后，公司将其操作程序手册更改为“每月质量审查”，将副本发送给审核员，并获得认证。
更大的不合规情况（“您说您会在 30 天内阅读并回复所有客户投诉，但我看到您拿着装满投诉的大邮袋，甚至没有打开袋子就把它们烧毁了！”）几乎注定会失败——这些事情表明组织文化无视适用的标准/要求。
这种事情通常需要进行全面重新审核，以向审核员证明您正在认真对待这些要求。
请记住，审计人员也要对其他人负责——通常是认证机构。
如果他们的审计存在问题，他们最终将失去开展审计的权力。
SSAE 16（SAS 70）下的审计是“我们说到做到”的审计。
您不能“不通过”审计，因为标准是您自己的，但您可以有“重大不符合项”（这是 AICPA/审计师的花哨说法，意思是“您不通过是因为您没有做到您说过的事！”）。
对于像我之前引用的示例段落这样的小事情，修复受影响的系统C并D要求密码并向审计师提交证据可能足以发布修订后的审计报告，表明已经解决了重大不符合项，但与针对特定标准的认证审计一样，如果审计师感觉到“组织文化”无视规则/要求，那么让他们同意在不进行全面重新审计的情况下重新发布报告将变得更加困难。