OSS Security features. Let's take a look at some of these security features that are built into OSS. So the first is, of course, SSL or TLS. This is HTTPS security, this is encryption of data in transit so there is an HTTPS endpoint for every single Alibaba Cloud region which OSS supports, so all of your data in transit can be encrypted via HTTPS. Access control, there's both bucket policy to set IP address whitelists and blacklists and set conditions on access like requiring HTTPS, and then there's bucket and object level ACL which determines whether or not objects can be read or written publicly or will require a signing key.

Then there's encryption for data at rest. We have two types of server side encryption, one is SSE-OSS which is where you use a managed encryption key built into the OSS surface. The other is SSE-KMS where you build or create your own key inside of our KMS, key management service and then you use that key to encrypt the contents of your bucket. Finally, there's identity and authentication. This is done via RAM and STS. STS is Alibaba Cloud Security Token Service This is how you generate temporary access tokens that get appended to the URLs of objects in your bucket, which allow you to access those objects, say, from a web browser, and RAM is what you use to create subaccounts under your Alibaba Cloud account.

You can set RAM policy that determines which of these subaccounts can access which buckets and which objects within each bucket, so you have fine grain control over access to objects and buckets via Ram and the STS token service. So bucket and object ACL is something you can figure at the time you create the bucket. There are basically three ACL policies: private, public read, and public read/write. With a private policy, any access to the objects in the bucket requires you to sign your request so you have to sign your request with an STS token.

Public read does not require you to sign requests for reading the content of the bucket but it does require you to sign requests to update, delete, or modify objects in the bucket. And then there's public read and write which allows full access to read, write, and modify objects in the bucket without signing your request. That's a very dangerous option and if you are using that, you should probably use it in concert with bucket policy so bucket policy is here on the right.

Bucket policy can apply to particular objects or to the whole bucket, and it allows you to set specific levels of permissions for RAM accounts, other Alibaba Cloud accounts or anonymous users. And what you can do is set levels of permissions like whether the anonymous user RAM account or other account is allowed to read, write, and modify objects and other conditions that the user has to fulfill such as, say, the request might have to come from a particular IP address range or a particular IP address might be blacklisted or banned.

You can also set conditions on the access method. For instance, you could, through bucket policy, require a user to use HTTPS. To secure data in transit, you can use HTTPS. If you open the preview pane for an object in your bucket, like you can see in the screenshot here on the right, there's a radio button which you can toggle on to turn on HTTPS support and then the URL for that object, which you can see in the box in the middle of the screenshot, will start with HTTPS and any requests to read that object will be encrypted using our SSL certificate.

You can also, if you like, use a client-side encryption library to encrypt data before it's even uploaded to OSS which will protect it both in transit and while it's at rest in the OSS service so that's another option. If you require even stronger protection, you can encrypt and decrypt objects outside of the OSS service and then simply upload the pre-encrypted content into OSS. On the server side, in addition to the technique I just mentioned where you can encrypt objects locally before uploading, we also offer two encryption methods that are built into OSS, which I discussed briefly before, there's SSE-KMS in which key material from our key management service is used to encrypt objects, then there's SSE-OSS which is where you use the default AES-256 key that's built into the OSS service. This is the easiest of the two to use, but KMS offers more customization and more security since you can use your own encryption key material.

So for identity and authentication, there's two mechanisms, there's RAM policy and STS. So RAM policy defines which operations a user is allowed to carry out in the OSS service and which buckets and objects those operations are allowed to be carried out on. That's the resource section in the JSON document shown on the left side of the slide. You can see here that the user is allowed to operate on any object inside the RAM test bucket and that permission does not extend to other buckets. The user who is using this RAM policy on the left can only manipulate objects inside of the RAM test bucket and at the top where you see Action, you can see that they are allowed to do two things, list objects and get objects, which means that they can read the content of this bucket, but they cannot delete objects and they cannot upload new objects.

So how has this access policy enforced? Well, when you make a request of the OSS API, you'll have to use your RAM user credentials to generate an STS token, which is a signing key. That key will be returned to your client, maybe your web browser, maybe the Alibaba Cloud command-line tools, and you'll attach that STS token to your requested OSS service and what OSS will do, is verify, number one, that that STS token is valid, and number two, that the operation you're trying to carry out matches the RAM policy, and if it doesn't match the RAM policy, the action is denied.

So this is how we control access to objects and buckets in the OSS service. You can also generate time-limited signed URLs that point to an object in a bucket, like the one shown on this slide here. If you pass this URL to someone, they can use this URL to temporarily access a resource in OSS. Once the URLs signature expires, then the URL will no longer allow the user to fetch the object in question. So this is a way to offer temporary access, say, either to an individual user or to a third-party application or an application running on an endpoint like a cell phone. Time-limited keys are typically a good idea because they limit access duration and access permissions more effectively than a long-lived key like an Alibaba Cloud AccessKey. And that's all for this section of the course. Thank you.