The document talks about multiple aspects of security, including physical security, data security, privacy, organizational/operational security (how the organization is designed so that security gets built into apps), and threat evasion (dealing with security problems when they do happen). The most interesting parts to me were the ones about development methodology: all new developers are trained about security (I went through some of this myself when I interned at Google), and all products are audited throughout the development process. The document rightfully points out that security must be designed into an application from the beginning and carefully managed thereafter; it can't be bolted on or "validated after the fact". Also interesting is the part about Google developing its web servers etc to only contain the outwards-facing features its apps need, rather than using something like Apache. This is a good way to make the code smaller and more auditable.
One of the points I didn't agree with was about Google's internal infrastructure making it hard to find user data even if someone does break in - for example, because data is distributed among multiple servers. I find this hard to believe. If someone breaks into the Google intranet, they also find all the developer documentation including API docs on how to read/write data from the storage systems. They can use these to find the relevant data. This argument sounds to me like security through obscurity. I'm sure however that there are other systems on top of the infrastructure that provide more protection beyond hoping that someone just won't figure out where the replicas of a given block are.
No comments:
Post a Comment