ºÝºÝߣ

Editor's Notes

• #7: When the Shared Responsibility model is not understood, an organization may tend to gravitate towards doing only what it knows today, meaning there may be policies or procedures that are incongruent or not practical to apply when it comes to a cloud vendor such as Amazon. Lower level infrastructure, such as the supporting utilities, physical security, logical security, physical infrastructure, attached storage, and so on, are now managed by the vendor, in this case, AWS. The need to manage a system level topography below what is within the Customer¡¯s realm of responsibility is no longer a directly manageable activity. Many attempts to attempt to convince or coerce a cloud vendor such as AWS will likely result in wasted time and effort, and lead to frustration with cloud vendors as a whole. At this point, I would strongly recommend relying upon the contractual agreement and obligations your organization has entered into with your cloud provider, and ensure those obligations, at minimum, meet the requirements of your organization¡¯s quality policy.
• #10: In the case of managing assets that are internal to the organization, such as an enterprise LIMS system, one would want to control and lock down assets the same way that traditional assets are managed. The large difference, in this particular scenario, is that the assets are hosted external to the corporate network. In this case, it is the VPN connection or the AWS Direct Connect which needs to be configured to properly allow data in motion to be handled the same as it is handled between different geographical locations in corporate offices. The assumption is that the company will treat off-prem assets the same as on-prem assets. At the end of the day, in each area of the VPC, you would want to apply the same logical restrictions on your assets running in the cloud as you would running on your corporate network; that is to say, you wouldn¡¯t want to treat them much differently. External assets would need to be evaluated on a case by case basis, taking into account data criticality, operational risk, regulatory risk, etc etc.
• #11: Jack be nimble, jack be quick, jack provisioned a datacenter with just one click. Keep keen eye over what projects your AWS infrastructure are supporting Keep an eye on how many version(s) of the same solution are floating around ¨C this will avoid the discussion of ¡°are my data CORRECT¡± Understand your IAM strategy. Integrate IAM as quickly as possible. Dispel any attribution issues as early as possible. Scenario ¨C data are being pushed via Kinesis Firehose into an S3 bucket and a RedShift table for real time analysis of a manufacturing environment ¨C you¡¯d want to be certain that the datapoints you¡¯re collecting can be properly attributed to the correct origin ¨C the correct data generating device or person.