在SaaS提供商提高安全标准（对客户可见并可控）之前，用户仍然需要控制潜在的合规风险。显然，将业务应用移出企业，安全是最大的问题。

看不到用户活动、没有监控和限制访问控制，SaaS对首席信息安全官（CISO）来说很严峻，特别是合规责任。为了减少安全问题，安全团队（特别是企业）必须做很多工作，包括：

• 积极参与采购，采取积极主动的态度并审核所有SaaS关系。
• 充分意识到数据合规问题，它围绕着每个SaaS应用。
• 拒绝不能提供足够可见度、活动监控或访问控制的供应商。

SaaS安全标准清单

SaaS还在起步阶段且发展迅速，提供商各不相同。因此，如果用户想评估第三方SaaS提供商的安全漏洞或能力，必须问对问题。例如：

不同的访问控制是如何形成颗粒状的？

显然，针对数据泄露，IT当前最大的问题是恶意或无意的误用用户凭据，特别是登录信息。因此，有效的数据保护需要了解用户活动，同样包括管理的变化。

什么指标可用于报告？

考虑下是否可以创建同时让首席信息主管、审计师以及董事会满意的报告呢？企业数据安全能否满足监管要求呢？它应该可以。

• 问问自己，这样获取的数据能否方便的集成到内部监控工具以防止数据竖井。为了确保万无一失，必须同时监控企业内部和SaaS应用（从一个集中的管理面板）。

最后，必须了解SaaS应用的业务，特别是涉及数据的。另外，必须知道应用是否处理客户的机密信息。这时就可以执行相关的合规清查。

SaaS安全问题

SaaS提供商需要保证用户不能查看彼此的数据。以下是SaaS的一些安全标准和措施：数据安全、数据局部性、网络安全、数据隔离、数据隐私、数据泄露、Web应用安全以及认证和授权。

客户安全顾虑

从行业角度来说，计算需要关注大量的属性，特别是安全方面的。起初，客户对安全期待非常高。他们不会允许数据被托管到共享环境。这意味着云提供商必须停止公有云方案，并专注于私有云。

另外，客户都很关心遵从性和提供商是否符合审计标准（SAS 70、 SOC 2、SOC 3 和SSAE 16）。有时，他们希望能够检查物理设施，一些SaaS供应商不允许这样做。这是一个大忌。长远来说，让SaaS供应商控制的越多，风险就越大。但是，一旦你了解了需求，就可以和某个云提供商合作，使安全水平让人满意。

SaaS安全维度

云计算的安全性或许是如今最热门的话题之一。考虑到SaaS安全是多维的且关系复杂。因此，要着眼于更大、全局的环境（物理、应用、网络安全）。但是IaaS/PaaS连同扩展性、可用性、性能以及集成也需要考虑到。

快速部署以及定制/回收/多租户是基于另一个维度，政策和程序则又是一个。因为基本上不可能在以上所有领域都做到最好，你可以根据用户的容忍程度来决定或定义安全。

事实上，用户通常在全面考虑之后，选择适当的安全技术或机制，再定义自己的安全指标。因此，建议尽力尝试以提供云计算安全保障的最佳实践。

云安全囊括了多个方面和工具。

一些涉及的问题包括：

• 窃听设备（路由器、电脑、物联网设备等等）；
• 失败的变更管理；
• 传输过程中的数据操纵和/或拦截；
• 社会工程等
• 内部人员的非法访问

以上是一些（不是全部）领域。不像内部部署的应用和云，公有云又加入了两个安全点，即因特网和内部的（但外部管理）云。

如今的第三方云供应商只向客户提供有限的信息。不幸的是，他们不能准确回答关于用户访问异常的问题。例如，SaaS供应商不能直接回答这个关键问题：“在组织里，谁可以修改权限？”然而，调查内部攻击时，这些信息很重要。

另外，对于正确引导SaaS供应商简化客户报告，还缺乏行业标准。即使有日志数据，如果在格式上未达成一致，企业客户也面临着挑战以及高昂的集成过程。

结论

SaaS提供商任务艰巨，他们必须提高安全的可见性和可控性，使用户相信他们有能力管理潜在的合规风险。将业务应用移出企业，通常要损失安全。

因此，首席信息安全官有责任减少安全问题。作为客户必须有一个安全清单，SaaS安全标准是如今的热门话题，SaaS供应商要赢得客户的信任必须解决这些问题。

以下是一些AWS的相关使用信息的分享，通过一些简单的步骤，便可以快速使用AWS。

什么是AWS免费使用套餐？

AWS 主要的服务都提供一定使用量范围内的免费使用套餐。免费使用套餐包括：Elastic Compute Cloud (EC2)中750 小时时长的 Amazon EC2 Linux 微型实例使用时间， Amazon EC2 Linux/UNIX或 RHEL 或 SLES 微型实例使用时间以及 Elastic Load Balancing 的使用时间等。在Simple Workflow (SWF)中，可免费启动 1 000 个 Amazon SWF 工作流执行。在Simple Queue Service (SQS) 和 Simple Notification Service (SNS)中，可与 Amazon Simple Notification Service 配合使用的 1 000 000 个请求、100 000 个 HTTP 通知和 1 000 份电子邮件通知等一系列的免费使用功能。

这些功能的使用都有免费使用额度，如果超出额度，将会产生一定的费用（参阅 各服务页面 获取向详细定价详情）。AWS免费使用套餐针对所有的新账户，而且适用于任何AWS地区。AWS提供的免费套餐，可以了解并启动新应用程序、测试云中现有的应用程序，或只是利用AWS 获取实践经验。

相关信息：( https://aws.amazon.com/cn/free/ )

如何使用AWS免费套餐？

要想快速使用AWS提供的免费套餐（Free Usage Tier），使用者需要注册AWS账户并订阅您可能要使用的服务，尽早完善AWS账户资料，包括信用卡信息。当用户的实际使用量超出免费使用套餐的限额后，AWS会收取相应的费用。为了方便使用，AWS 提供了多种简单易用的功能，包括监控并支付一个或多个账户的账单。

AWS 免费使用套餐适用于在所有 AWS 地区里参与的服务：美国东部（弗吉尼亚北部）、美国西部（俄勒冈）、美国西部（加利福尼亚北部）、欧洲（爱尔兰）、亚太地区（新加坡）、亚太地区（东京）、亚太地区（悉尼）和南美洲（圣保罗）。免费使用量每月计算一次（所有地区）并自动应用到账单中，免费使用量不能累计。

免费套餐仅适用于新的 AWS 客户，可在注册 AWS 后的 12 月内均可试用。当您的免费试用过期或者您的应用程序使用量超过了免费使用套餐限额，您只需支付标准的按使用量付费服务费率（请参阅 服务页面 获取完整的定价信息）。

这些免费套餐在 12 个月后仍不会过期，新老 AWS 均可无限期使用。

Redis提供了许多提高和维护高效内存数据库使用的工具。在无需额外配置应用层的前提下，Redis独特的数据类型、指令和命令调优就可以满足应用的需求，但是错误的配置，更确切的说那些机外设备可能导致操作麻烦和性能问题。虽然导致了一些令人头疼的问题，但是解决方案是存在的，而且解决方案可能比我们预期的简单。

本系列文章介绍了使用Redis时遇到的一些令人头疼的问题，以及该解决这些问题。这些内容基于我们在运行上千个Redis数据库实例时的真实经历。

复制缓冲区限制

复制缓冲区主从服务器同步数据时保存数据的内存区域。在一个完整的主从同步中，初始化阶段同步时，主服务器在复制缓冲区中保存数据的变化。初始化阶段完成后，缓冲的内容发送到从服务器。这个过程可能会遇到缓冲区的容量限制，达到最大容量时复制会重新开始。为了避免这种情况，缓冲区需要依据复制过程中变化的类型和数量进行初始化配置。例如，一个小缓冲区可以存储少量的变化数据，但当变化比较多、比较大时，我们需要大缓冲区。一个更复杂的解决方案会更详细的设置缓冲区，避免冗长、大的复杂过程耗尽缓冲区（如果缓冲区太小）。最终，这个解决方案需要微调特定的数据库。

当256MB的硬限制到达时，或者软限制到达且持续60秒时，默认的复制链路会断裂（导致同步从头开始）。许多情况下，特别是写负载高和从服务器带宽不足的情况下，负载过程都无法结束。这可能导致无限循环，主Redis持续的将整个数据集复制到硬盘，这可以导致高速率的I/O操作，消耗高达三倍的额外内存。此外，无限循环将导致从服务器无法赶上主服务器，无法与主服务器完全同步。

一个简单地解决方案是提高输出从缓冲区，将软硬限制都设置为512MB，这个解决方案可以很快的提高结果。

因为有很多重新配置，所以务必理解：

1.  在增加复制缓冲区尺寸前，我们必须确保机器上有足够的内存。

2.  Redis内存使用计算不考虑复制缓冲区容量。

以上是本文介绍的第一个问题。如我们上面谈到的，尽管有复制缓冲区限制，合适的配置是可以良好运行的。下面我们谈谈主从复制的另一问题。我们将深入讨论完成该过程所需的时间和可能导致麻烦的一些配置问题。

复制超时

如我们先前讨论的，Redis的复制过程包括两个同步阶段：初始化阶段和进行阶段。尽管进行阶段很稳定（只要保持主从服务器间的链路即可），初始化阶段不那么容易完成。成功的完成初始化同步不止依赖于复制缓冲区分配的内存，还基于该步骤花费的时间。

你可能想起来了，初始化同步步骤包括后台保存以及整个数据主导从的传播。基于数据库容量和网络连接质量，这可能是一个很长的过程。如果阶段耗时太久，Redis可能会达到复制超时设置，这可能会导致初始阶段重复进行。这种情况下，你会发现从Redis日志文档充斥着这些信息：

[28618] 21 Jul 00:33:36.031 * Connecting to MASTER 10.60.228.106:25994
[28618] 21 Jul 00:33:36.032 * MASTER <-> SLAVE sync started
[28618] 21 Jul 00:33:36.032 * Non blocking connect for SYNC fired the event.
[28618] 21 Jul 00:33:36.032 * Master replied to PING, replication can continue...
[28618] 21 Jul 00:33:36.032 * Partial resynchronization not possible (no cached master)
[28618] 21 Jul 00:33:36.032 * Full resync from master: 549907b03661629665eb90846ea921f23de6c961:2537453

Redis复制超时的默认值是60秒（见redis.conf文件的repl-timeout指令，或使用redis-cli运行“config get repl-timeout”）。这个时间可能很短，特别是当你有：

• 低速存储器：如果主服务器或从服务器是基于低速存储器的，如果是主服务器将导致后台进程花费很多时间；如果是服务器磁盘读写数据时间将延长。
• 大数据集：更大的数据集将需要更长的存储时间和传输时间。
• 网络性能：当主服务器和从服务器的网络链路有限制带宽和高延迟时，这会直接影响数据传输传输速率。

我们可以通过将复制超时设置为更合适的值来修正这个问题。首先是一个可接受复制数据库的的估计时间。第一步，检查Redis通过BGSAVE指令和检查相关行（如“Background saving started by pid nnn ”表示进程开始，“ Background saving terminated with success”表示进程结束）的日志文档执行后台进程所花的时间。然后，测量CN将主服务器上的结果RDB文件拷贝到从服务器硬盘所需的时间。最后，测量从硬盘加载数据实际消耗的时间（如重启Redis，在日志文件中寻找“DB loaded from disk”行）。这些方法可以大致估计复制超时值，保险起见，我们可能需要在上面加上10~20%。

依据测量值设定了超时后，我们可以通过让从服务器执行几次完整的同步和检查日志文件来测量复制的实际耗时。如果可能的话，在日常不同的时刻重复这个操作，确保在不同的负载下系统的表现良好。最后，切记随着数据库的增长，我们需要定时检查超时设置值。

以上描述的是Redis复制问题。复制是保持数据库可用、扩展数据库可读性的有力工具，不过注意复制的默认设置，确保依照实际使用情况配置数据库。下面我们谈谈客户端缓冲区。在有些情况下，客户端缓冲区会带来很多问题。

客户端缓冲区

你大概已经知道Redis是一个内存数据库，这意味着所有的数据都由RAM直接管理和提供的。因此Redis有着卓越的交付性能，Redis可以以亚毫秒级的延迟处理几万、几十万的请求。RAM是当下最快的存储技术——为了更好的理解延迟数字，请看以下数据：

Latency Comparison Numbers
--------------------------
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns 14x L1 cache
Mutex lock/unlock 25 ns
Main memory reference 100 ns 20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy 3,000 ns
Send 1K bytes over 1 Gbps network 10,000 ns 0.01 ms
Read 4K randomly from SSD* 150,000 ns 0.15 ms
Read 1 MB sequentially from memory 250,000 ns 0.25 ms
Round trip within same datacenter 500,000 ns 0.5 ms
Read 1 MB sequentially from SSD* 1,000,000 ns 1 ms 4X memory
Disk seek 10,000,000 ns 10 ms 20x datacenter roundtrip
Read 1 MB sequentially from disk 20,000,000 ns 20 ms 80x memory, 20X SSD
Send packet CA->Netherlands->CA 150,000,000 ns 150 ms

Notes
-----
1 ns = 10-9 seconds
1 ms = 10-3 seconds
* Assuming ~1GB/sec SSD

Credit
------
By Jeff Dean: http://research.google.com/people/jeff/
Originally by Peter Norvig: http://norvig.com/21-days.html#answers

Contributions
-------------
Some updates from: https://gist.github.com/2843375
Great 'humanized' comparison version:https://gist.github.com/2843375
Visual comparison chart: http://i.imgur.com/k0t1e.png
Nice animated presentation of the data: http://prezi.com/pdkvgys-r0y6/latency-numbers-for-programmers-web-development/
- See more at:http://redislabs.com/blog/top-redis-headaches-for-devops-client-buffers#sthash.9rHluMPF.dpuf

Redis，如同它的名字和设计，是一个移动服务器，客户端（通常）通过网络连接Redis。这种情况下，客户端请求返回客户端的时间将显著长于Redis CPU从RAM读取数据的时间。这意味着如果没有客户端缓冲区的话，Redis的主要差异与在该段时间对服务的响应有关。

客户端缓冲区组成了服务客户请求所需的内存空间，Redis的每个连接都配有自己的缓冲区空间。处理请求后，Redis把响应数据复制到客户端缓冲区，然后继续处理下一个请求，与此同时，请求客户端通过网络连接读取数据。Redis客户端缓冲区配置在redis.conf文件，通过client-output-buffer-limit normal指令配置（你可以在运行时通过config get client-output-buffer-limit指令获取设置）。默认的redis.conf文件定义如下：

client-output-buffer-limit normal 0 0 0

这些数值分别代表缓冲区软限制，硬限制和以秒为单位的超时（类似于复制缓冲区）。当Redis终止连接时，这些值提供保护——不需要客户读取回复——当缓冲区尺寸达到a）软限制并且保持状态直到超时b）硬限制。将这些数值都设为0意味着关闭保护。

不过，和复制缓冲区不同的是客户端缓冲区来自Redis数据内存空间。可以通过maxmemory指令设置Redis的总内存值，达到极限后，Redis将应用其配置的驱逐策略（由maxmemory-policy 指令定义）。因此，低性能的客户或大量的同时连接可能会因为数据集尺寸和客户端缓冲区达到内存限制导致Redis实例过早的驱逐键或禁止更新。

由于生命周期的相对性，一个客户端不需要降低性能就可能导致这种现象。因为RAM读取和网络读取存在着很大的速度差异，过多的客户端缓冲区很可能耗尽Redis内存，即使是在高性能的客户端和网络连接中。例如，考虑下（万恶的）KEYS指令，这个指令触发后，Redis将会把整个键的名空间拷贝给客户端缓冲区。如果我们的数据库有很多键，这很可能导致驱逐。

警告：使用KEYS时务必要谨慎，不要在生产环境下使用KEYS。使用KEYS除了可能导致上文提到的驱逐外，还可能会在很长时间内封锁Redis。

KEYS不是唯一一个可能导致这种情况的指令。类似的指令还有SMEMBERS，HGETALL，LRANGE和ZRANGE（以及与这些指令相关的指令），当值（或范围）足够大，或者当有很多公开连接（每个连接都需要单独的缓冲区）时，这些指令可能导致类似的现象。

我们强烈推荐谨慎负责的使用这些指令。我们推荐大家使用SCAN家族指令替代这些指令，v2.8版本加入了SCAN指令。SCAN指令不仅允许Redis在后续的SCAN调用间继续处理请求，还降低了耗尽客户端缓冲区的概率。

客户端缓冲区是Redis内存需求和管理常常会忽略的方面。客户端缓冲区的默认设置有风险，很可能导致内存耗尽。我们要有依据的设置缓冲区阈值—考虑“maxmemory”设置，当下和预测内存使用，应用流量模式。谨慎的使用先前提到的指令可以避免那些令人头疼的问题。欢迎关注我们后续的文章。