Here are the types of data protection usually provided by cloud service providers. Essentially, there are two types, like there are in most environments. You have classic access control, which is an active protection provided by operating system software. Then you also have cryptography, which is more of a passive protection, so while the access control requires that the software be actively running and actively mediating on accesses cryptography, once you've changed the data from plain text to cipher text, the protection remains in place until you transform it back to plain text. Now, in the world of cloud systems, they tend to have similar administrative controls which may be a little weird for people who are used to other types of cryptography, but that's the way they do it in the cloud. So the way the whole system is managed is you have mastered administrators and then under them sub administrators, and then at some level individuals and projects are granted access to instances and have resources. Now, when they start applications running or set things up to start the applications running, they inherit the access rights from a user or a project ID. It works on normal operating systems. The point being, of course, that at the cloud consumer level, you have a master administrator, who then establishes access rights for individuals and projects within the scope of that enterprise or project. Now, managing crypto, a default case in the cloud world is that a crypto manager, a software process, issues crypto keys to people and projects. The keys grant access to encrypted resources or they protect resources with encryption, you look at it either way, and an application will inherit access to keys from its user or project ID. If you have access to the information and it's encrypted, you need access to the keys in order to be able to read it. Keys are distributed and controlled through the same type of mechanism as the access control. That sometimes it's a completely separate system, sometimes they're tightly integrated, sometimes it's completely under the hood and say you can't see it. What's the difference? Well, the point is it's hard to tell what the difference is if you're just thinking about access control. Now if you're also thinking about, say, a broader range of threats, the nice thing about crypto protections is, even if the device dies or the entire system shuts down, you still have your protection on the data if it's encrypted. So you don't lose the encryption simply because the power goes away. Even better, the keys are generally inaccessible if the system is down, you need to have all the key management software running in order to retrieve the keys to get to your data. Access control management. Here are some ways that you can manipulate and establish access controls for things in your system. There's the classic access control list which then you can apply to identifiable resources and instances of resources in your collection of things that you have within your cloud system. There's also this notion about access control tags and in some ways, a tag is a little bit like a group, but in other ways it's actually more like a specialized access control list in that each tag has an access list associated with that, and anything marked with that tag enforces the access rights on its access control list. Another issue and something that'll come up in the assignment is granularity of resource management. So if you have your coarse grained or fine grained. So the coarse grained, essentially, you'll have a basket full of resources, and in a course grained system, you can control who has access to the basket, what types of accesses does they have? In a fine grained one, you can look inside the basket and control access to the individual objects. Like I might be allowed to reach in and pull this object out, modify it, and then put it back. That's fine grain and you can have different layers of fine grain depending upon how deep into the objects you want to go. With something like tagging you can go actually quite deep and put a tag on something inside something, inside something. If you're assessing the granularity for access control and cryptography, you're essentially saying, okay, what's the largest resource controll in terms of the hierarchy of resources? The Uber resource that has sub resources inside it. We have a couple examples in a minute, and the same thing with crypto keys. What's the largest thing you can encrypt as a thing, and what's the smallest resource you can encrypt as a single thing. Okay, file oriented service as well with access control, file systems tend to be incredibly flexible. You can control it at the user level, you can control project or group level, you can control volumes, you can control individual files, you can control access to folders and directories, control how far you can go down in the hierarchy by controlling the individual directories. There's a lot of control you have. Now, in encryption, it's a little different when you're looking at file oriented services. Oh, yes, you can encrypt the entire volume. That's one of your choices, or you can go down and you can encrypt the file. Now, some systems, I remember the old Apple Macos app used to have it, where you could say, I want to encrypt my home directory, and it would encrypt your home directory. Now, that's a little misleading because the way you encrypt with a file system is you encrypt the file at a time. The directory isn't one clump of disk that you can simply go down and encrypt. You have to actually do the files individually. That's why that's written that way. Now, it could be with particular vendors. They may have found other ways of organizing their system so that maybe it's possible to encrypt on a per something else level within a file system. But this is the way it works out in lot of cases. Okay, bucket oriented services. Now, this is in a general notion, individual vendors may do things a little differently. But a lot of time the access control at the macro level is you either can access the bucket or not, and you can either read and write it or read-only or no access, and then you have the individually identified objects within the bucket need to one of those can have access control on it. That's fairly typical. Similarly with encryption, you can either encrypt the whole bucket or individual objects in the bucket. Now, if you're encrypting the entire bucket, a lot of times that is handled automatically by the cloud service provider. They will just put bucketed encryption in by default so that when the system is down for whatever reason or there's a hard drive that gets taken out of service you got all that stuff encrypted and you don't have to worry about leaking the contents. Other data services, relational databases. We had a video in the previous module well, a couple of them probably they talked about access control for relational. Now, for key value databases, you're going to have a for a single database file, database, key value document., you'll have access control that says, can you read or write the document? Of course. Now, it's possible if you have a really clever system that I might be able to use tagging within the key value system to enforce other access restrictions. It's not clear to me anybody does that, but it is possible. Again, even other services like Hadoop and such you have the same sort of situation at some level you can control access to aggregates and at some level it's an individuals, and sometimes you can do both.
