Amazon WorkDocs

(1)

Amazon WorkDocs

Administration Guide

(2)

Amazon WorkDocs: Administration Guide

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

What is Amazon WorkDocs?

Amazon WorkDocs is a fully managed, secure enterprise storage and sharing service with strong administrative controls and feedback capabilities that improve user productivity. Files are stored in the cloud, safely and securely. Your user's files are only visible to them, and their designated contributors and viewers. Other members of your organization do not have access to other user's files unless they are specifically granted access.

Users can share their files with other members of your organization for collaboration or review. The Amazon WorkDocs client applications can be used to view many different types of files, depending on the Internet media type of the file. Amazon WorkDocs supports all common document and image formats, and support for additional media types is constantly being added.

For more information, see Amazon WorkDocs.

Accessing Amazon WorkDocs

Administrators use the Amazon WorkDocs console to create and deactivate Amazon WorkDocs sites. With the admin control panel, they can manage users, storage, and security settings. For more information, see Managing Amazon WorkDocs from the site admin control panel (p. 25) and Inviting and managing Amazon WorkDocs users (p. 29).

Non-administrative users use the client applications to access their files. They never use the Amazon WorkDocs console or the administration dashboard. Amazon WorkDocs offers several different client applications and utilities:

• A web application used for document management and reviewing.

• Native apps for mobile devices used for document review.

• Amazon WorkDocs Drive, an app that synchronizes a folder on your macOS or Windows desktop with your Amazon WorkDocs ﬁles.

For more information about how users can download Amazon WorkDocs clients and edit their ﬁles, and which ﬁle types are supported, see:

• Getting started with Amazon WorkDocs

• Editing ﬁles

• Supported ﬁle types

Pricing

With Amazon WorkDocs, there are no upfront fees or commitments. You pay only for active user accounts, and the storage you use. For more information, see Pricing.

How to get started

To get started with Amazon WorkDocs, see Creating an Amazon WorkDocs site (p. 18).

(6)

Sign up for AWS

Prerequisites for Amazon WorkDocs

To set up new Amazon WorkDocs sites, or manage existing sites, you must complete the following tasks.

Tasks

• Sign up for AWS (p. 2)

• Create IAM users and groups (recommended) (p. 2)

Sign up for AWS

Your AWS account gives you access to all services, but you are charged only for the resources that you use.

If you do not have an AWS account, complete the following steps to create one.

To sign up for an AWS account

1. Open https://portal.aws.amazon.com/billing/signup.

2. Follow the online instructions.

Part of the sign-up procedure involves receiving a phone call and entering a veriﬁcation code on the phone keypad.

Your AWS root account credentials identify you to services in AWS and grant you unlimited use of your AWS resources, such as your Amazon WorkDocs sites.

Create IAM users and groups (recommended)

To allow other users to set up new Amazon WorkDocs sites, or manage existing sites, without sharing your security credentials, use AWS Identity and Access Management (IAM). We recommend that everyone work as an IAM user, even the account owner. You should create an IAM user for yourself, give that IAM user administrative privileges, and use it for all your work.

For more information, see Identity and access management for Amazon WorkDocs (p. 3).

(7)

Identity and access management

Security in Amazon WorkDocs

Cloud security at AWS is the highest priority. As an AWS customer, you beneﬁt from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.

Security is a shared responsibility between AWS and you. The shared responsibility model describes this as security of the cloud and security in the cloud:

• Security of the cloud – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the eﬀectiveness of our security as part of the AWS compliance programs. To learn about the compliance programs that apply to Amazon WorkDocs, see AWS Services in Scope by Compliance Program.

• Security in the cloud – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.

This documentation helps you understand how to apply the shared responsibility model when using Amazon WorkDocs. The following topics show you how to conﬁgure Amazon WorkDocs to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Amazon WorkDocs resources.

Topics

• Identity and access management for Amazon WorkDocs (p. 3)

• Logging and monitoring in Amazon WorkDocs (p. 14)

• Compliance validation for Amazon WorkDocs (p. 16)

• Resilience in Amazon WorkDocs (p. 17)

• Infrastructure security in Amazon WorkDocs (p. 17)

Identity and access management for Amazon WorkDocs

AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be authenticated (signed in) and authorized (have permissions) to use Amazon WorkDocs resources. IAM is an AWS service that you can use with no additional charge.

Topics

• Audience (p. 4)

• Authenticating with identities (p. 4)

• Managing access using policies (p. 6)

• How Amazon WorkDocs works with IAM (p. 7)

• Amazon WorkDocs identity-based policy examples (p. 9)

(8)

Audience

• Troubleshooting Amazon WorkDocs identity and access (p. 12)

Audience

How you use AWS Identity and Access Management (IAM) diﬀers, depending on the work that you do in Amazon WorkDocs.

Service user – If you use the Amazon WorkDocs service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more Amazon WorkDocs features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in Amazon WorkDocs, see Troubleshooting Amazon WorkDocs identity and access (p. 12).

Service administrator – If you're in charge of Amazon WorkDocs resources at your company, you probably have full access to Amazon WorkDocs. It's your job to determine which Amazon WorkDocs features and resources your employees should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with Amazon WorkDocs, see How Amazon WorkDocs works with IAM (p. 7).

IAM administrator – If you're an IAM administrator, you might want to learn details about how you can write policies to manage access to Amazon WorkDocs. To view example Amazon WorkDocs identity- based policies that you can use in IAM, see Amazon WorkDocs identity-based policy examples (p. 9).

Authenticating with identities

Authentication is how you sign in to AWS using your identity credentials. For more information about signing in using the AWS Management Console, see Signing in to the AWS Management Console as an IAM user or root user in the IAM User Guide.

You must be authenticated (signed in to AWS) as the AWS account root user, an IAM user, or by assuming an IAM role. You can also use your company's single sign-on authentication or even sign in using Google or Facebook. In these cases, your administrator previously set up identity federation using IAM roles.

When you access AWS using credentials from another company, you are assuming a role indirectly.

To sign in directly to the AWS Management Console, use your password with your root user email address or your IAM user name. You can access AWS programmatically using your root user or IAM users access keys. AWS provides SDK and command line tools to cryptographically sign your request using your credentials. If you don't use AWS tools, you must sign the request yourself. Do this using Signature Version 4, a protocol for authenticating inbound API requests. For more information about authenticating requests, see Signature Version 4 signing process in the AWS General Reference.

Regardless of the authentication method that you use, you might also be required to provide additional security information. For example, AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account. To learn more, see Using multi-factor authentication (MFA) in AWS in the IAM User Guide.

AWS account root user

When you ﬁrst create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your ﬁrst IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.

(9)

Authenticating with identities

IAM users and groups

An IAM user is an identity within your AWS account that has speciﬁc permissions for a single person or application. An IAM user can have long-term credentials such as a user name and password or a set of access keys. To learn how to generate access keys, see Managing access keys for IAM users in the IAM User Guide. When you generate access keys for an IAM user, make sure you view and securely save the key pair. You cannot recover the secret access key in the future. Instead, you must generate a new access key pair.

An IAM group is an identity that speciﬁes a collection of IAM users. You can't sign in as a group. You can use groups to specify permissions for multiple users at a time. Groups make permissions easier to manage for large sets of users. For example, you could have a group named IAMAdmins and give that group permissions to administer IAM resources.

Users are diﬀerent from roles. A user is uniquely associated with one person or application, but a role is intended to be assumable by anyone who needs it. Users have permanent long-term credentials, but roles provide temporary credentials. To learn more, see When to create an IAM user (instead of a role) in the IAM User Guide.

IAM roles

An IAM role is an identity within your AWS account that has speciﬁc permissions. It is similar to an IAM user, but is not associated with a speciﬁc person. You can temporarily assume an IAM role in the AWS Management Console by switching roles. You can assume a role by calling an AWS CLI or AWS API operation or by using a custom URL. For more information about methods for using roles, see Using IAM roles in the IAM User Guide.

IAM roles with temporary credentials are useful in the following situations:

• Temporary IAM user permissions – An IAM user can assume an IAM role to temporarily take on diﬀerent permissions for a speciﬁc task.

• Federated user access – Instead of creating an IAM user, you can use existing identities from AWS Directory Service, your enterprise user directory, or a web identity provider. These are known as federated users. AWS assigns a role to a federated user when access is requested through an identity provider. For more information about federated users, see Federated users and roles in the IAM User Guide.

• Cross-account access – You can use an IAM role to allow someone (a trusted principal) in a diﬀerent account to access resources in your account. Roles are the primary way to grant cross-account access.

However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the diﬀerence between roles and resource-based policies for cross-account access, see How IAM roles diﬀer from resource-based policies in the IAM User Guide.

• Cross-service access – Some AWS services use features in other AWS services. For example, when you make a call in a service, it's common for that service to run applications in Amazon EC2 or store objects in Amazon S3. A service might do this using the calling principal's permissions, using a service role, or using a service-linked role.

• Principal permissions – When you use an IAM user or role to perform actions in AWS, you are considered a principal. Policies grant permissions to a principal. When you use some services, you might perform an action that then triggers another action in a diﬀerent service. In this case, you must have permissions to perform both actions. To see whether an action requires additional dependent actions in a policy, see in the Service Authorization Reference.

• Service role – A service role is an IAM role that a service assumes to perform actions on your behalf.

An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see Creating a role to delegate permissions to an AWS service in the IAM User Guide.

• Service-linked role – A service-linked role is a type of service role that is linked to an AWS service.

The service can assume the role to perform an action on your behalf. Service-linked roles appear

(10)

Managing access using policies

in your IAM account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.

• Applications running on Amazon EC2 – You can use an IAM role to manage temporary credentials for applications that are running on an EC2 instance and making AWS CLI or AWS API requests.

This is preferable to storing access keys within the EC2 instance. To assign an AWS role to an EC2 instance and make it available to all of its applications, you create an instance proﬁle that is attached to the instance. An instance proﬁle contains the role and enables programs that are running on the EC2 instance to get temporary credentials. For more information, see Using an IAM role to grant permissions to applications running on Amazon EC2 instances in the IAM User Guide.

To learn whether to use IAM roles or IAM users, see When to create an IAM role (instead of a user) in the IAM User Guide.

Managing access using policies

You control access in AWS by creating policies and attaching them to IAM identities or AWS resources. A policy is an object in AWS that, when associated with an identity or resource, deﬁnes their permissions.

You can sign in as the root user or an IAM user, or you can assume an IAM role. When you then make a request, AWS evaluates the related identity-based or resource-based policies. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. For more information about the structure and contents of JSON policy documents, see Overview of JSON policies in the IAM User Guide.

Administrators can use AWS JSON policies to specify who has access to what. That is, which principal can perform actions on what resources, and under what conditions.

Every IAM entity (user or role) starts with no permissions. In other words, by default, users can do nothing, not even change their own password. To give a user permission to do something, an administrator must attach a permissions policy to a user. Or the administrator can add the user to a group that has the intended permissions. When an administrator gives permissions to a group, all users in that group are granted those permissions.

IAM policies deﬁne permissions for an action regardless of the method that you use to perform the operation. For example, suppose that you have a policy that allows the iam:GetRole action. A user with that policy can get role information from the AWS Management Console, the AWS CLI, or the AWS API.

Identity-based policies

Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see Creating IAM policies in the IAM User Guide.

Identity-based policies can be further categorized as inline policies or managed policies. Inline policies are embedded directly into a single user, group, or role. Managed policies are standalone policies that you can attach to multiple users, groups, and roles in your AWS account. Managed policies include AWS managed policies and customer managed policies. To learn how to choose between a managed policy or an inline policy, see Choosing between managed policies and inline policies in the IAM User Guide.

Resource-based policies

Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource- based policies are IAM role trust policies and Amazon S3 bucket policies. In services that support resource- based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform

(11)

How Amazon WorkDocs works with IAM

on that resource and under what conditions. You must specify a principal in a resource-based policy.

Principals can include accounts, users, roles, federated users, or AWS services.

Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy.

Access control lists

Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.

Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see Access control list (ACL) overview in the Amazon Simple Storage Service Developer Guide.

Other policy types

AWS supports additional, less-common policy types. These policy types can set the maximum permissions granted to you by the more common policy types.

• Permissions boundaries – A permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based policy can grant to an IAM entity (IAM user or role).

You can set a permissions boundary for an entity. The resulting permissions are the intersection of entity's identity-based policies and its permissions boundaries. Resource-based policies that specify the user or role in the Principal ﬁeld are not limited by the permissions boundary. An explicit deny in any of these policies overrides the allow. For more information about permissions boundaries, see Permissions boundaries for IAM entities in the IAM User Guide.

• Service control policies (SCPs) – SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU) in AWS Organizations. AWS Organizations is a service for grouping and centrally managing multiple AWS accounts that your business owns. If you enable all features in an organization, then you can apply service control policies (SCPs) to any or all of your accounts. The SCP limits permissions for entities in member accounts, including each AWS account root user. For more information about Organizations and SCPs, see How SCPs work in the AWS Organizations User Guide.

• Session policies – Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The resulting session's permissions are the intersection of the user or role's identity-based policies and the session policies.

Permissions can also come from a resource-based policy. An explicit deny in any of these policies overrides the allow. For more information, see Session policies in the IAM User Guide.

Note

Amazon WorkDocs doesn't support Service Control Policies for Slack Organizations.

Multiple policy types

When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see Policy evaluation logic in the IAM User Guide.

How Amazon WorkDocs works with IAM

Before you use IAM to manage access to Amazon WorkDocs, you need to understand which IAM features are available to use with Amazon WorkDocs. To get a high-level view of how Amazon WorkDocs and other AWS services work with IAM, see AWS services that work with IAM in the IAM User Guide.

Topics

(12)

How Amazon WorkDocs works with IAM

• Amazon WorkDocs identity-based policies (p. 8)

• Amazon WorkDocs resource-based policies (p. 9)

• Authorization based on Amazon WorkDocs tags (p. 9)

• Amazon WorkDocs IAM roles (p. 9)

Amazon WorkDocs identity-based policies

With IAM identity-based policies, you can specify allowed or denied actions. Amazon WorkDocs supports speciﬁc actions. To learn about the elements that you use in a JSON policy, see IAM JSON policy

elements reference in the IAM User Guide.

Actions

Administrators can use AWS JSON policies to specify who has access to what. That is, which principal can perform actions on what resources, and under what conditions.

The Action element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Policy actions usually have the same name as the associated AWS API operation. There are some exceptions, such as permission-only actions that don't have a matching API operation. There are also some operations that require multiple actions in a policy. These additional actions are called dependent actions.

Include actions in a policy to grant permissions to perform the associated operation.

Policy actions in Amazon WorkDocs use the following preﬁx before the action: workdocs:. For example, to grant someone permission to run the Amazon WorkDocs DescribeUsers API operation, you include the workdocs:DescribeUsers action in their policy. Policy statements must include either an Action or NotAction element. Amazon WorkDocs deﬁnes its own set of actions that describe tasks that you can perform with this service.

To specify multiple actions in a single statement, separate them with commas as follows:

"Action": [

"workdocs:DescribeUsers", "workdocs:CreateUser"

You can specify multiple actions using wildcards (*). For example, to specify all actions that begin with the word Describe, include the following action:

"Action": "workdocs:Describe*"

Note

To ensure backward compatibility, include the zocalo action. For example:

"Action": [

"zocalo:*",

"workdocs:*"

],

To see a list of Amazon WorkDocs actions, see Actions deﬁned by Amazon WorkDocs in the IAM User Guide.

Resources

Amazon WorkDocs does not support specifying resource ARNs in a policy.

(13)

Identity-based policy examples

Condition keys

Amazon WorkDocs does not provide any service-speciﬁc condition keys, but it does support using some global condition keys. To see all AWS global condition keys, see AWS global condition context keys in the IAM User Guide.

Examples

To view examples of Amazon WorkDocs identity-based policies, see Amazon WorkDocs identity-based policy examples (p. 9).

Amazon WorkDocs resource-based policies

Amazon WorkDocs does not support resource-based policies.

Authorization based on Amazon WorkDocs tags

Amazon WorkDocs does not support tagging resources or controlling access based on tags.

Amazon WorkDocs IAM roles

An IAM role is an entity within your AWS account that has speciﬁc permissions.

Using temporary credentials with Amazon WorkDocs

You can use temporary credentials to sign in with federation, assume an IAM role, or to assume a cross- account role. You obtain temporary security credentials by calling AWS STS API operations such as AssumeRole or GetFederationToken.

Amazon WorkDocs supports using temporary credentials.

Service-linked roles

Service-linked roles allow AWS services to access resources in other services to complete an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An IAM administrator can view but not edit the permissions for service-linked roles.

Amazon WorkDocs does not support service-linked roles.

Service roles

This feature allows a service to assume a service role on your behalf. This role allows the service to access resources in other services to complete an action on your behalf. Service roles appear in your IAM account and are owned by the account. This means that an IAM administrator can change the permissions for this role. However, doing so might break the functionality of the service.

Amazon WorkDocs does not support service roles.

Amazon WorkDocs identity-based policy examples

By default, IAM users and roles don't have permission to create or modify Amazon WorkDocs resources.

They also can't perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform speciﬁc API operations on the speciﬁed resources they need. The administrator must then attach those policies to the IAM users or groups that require those permissions.

Note

To ensure backward compatibility, include the zocalo action in your policies. For example:

(14)

{ "Version": "2012-10-17", "Statement": [

{

"Sid": "VisualEditor0", "Effect": "Deny", "Action": [ "zocalo:*", "workdocs:*"

],

"Resource": "*"

} ] }

To learn how to create an IAM identity-based policy using these example JSON policy documents, see Creating policies on the JSON tab in the IAM User Guide.

Topics

• Policy best practices (p. 10)

• Using the Amazon WorkDocs console (p. 10)

• Allow users to view their own permissions (p. 11)

• Allow users read-only access to Amazon WorkDocs resources (p. 11)

• More Amazon WorkDocs identity-based policy examples (p. 12)

Policy best practices

Identity-based policies are very powerful. They determine whether someone can create, access, or delete Amazon WorkDocs resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:

• Get started using AWS managed policies – To start using Amazon WorkDocs quickly, use AWS managed policies to give your employees the permissions they need. These policies are already available in your account and are maintained and updated by AWS. For more information, see Get started using permissions with AWS managed policies in the IAM User Guide.

• Grant least privilege – When you create custom policies, grant only the permissions required to perform a task. Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later. For more information, see Grant least privilege in the IAM User Guide.

• Enable MFA for sensitive operations – For extra security, require IAM users to use multi-factor authentication (MFA) to access sensitive resources or API operations. For more information, see Using multi-factor authentication (MFA) in AWS in the IAM User Guide.

• Use policy conditions for extra security – To the extent that it's practical, deﬁne the conditions under which your identity-based policies allow access to a resource. For example, you can write conditions to specify a range of allowable IP addresses that a request must come from. You can also write conditions to allow requests only within a speciﬁed date or time range, or to require the use of SSL or MFA. For more information, see IAM JSON policy elements: Condition in the IAM User Guide.

Using the Amazon WorkDocs console

To access the Amazon WorkDocs console, you must have a minimum set of permissions. Those permissions must allow you to list and view the details of the Amazon WorkDocs resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for IAM user or role entities.

(15)

To ensure that those entities can use the Amazon WorkDocs console, also attach the following AWS managed policies to the entities. For more information attaching policies, see Adding permissions to a user in the IAM User Guide.

• AmazonWorkDocsFullAccess

• AWSDirectoryServiceFullAccess

• AmazonEC2FullAccess

These policies grant an IAM user full access to Amazon WorkDocs resources, AWS Directory Service operations, and the Amazon EC2 operations that Amazon WorkDocs needs in order to work properly.

You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that you're trying to perform.

Allow users to view their own permissions

This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.

{ "Version": "2012-10-17", "Statement": [

{

"Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [

"iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies",

"iam:GetUser"

],

"Resource": ["arn:aws:iam::*:user/${aws:username}"]

}, {

"Sid": "NavigateInConsole", "Effect": "Allow",

"Action": [

"iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy",

"iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies",

"iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers"

],

"Resource": "*"

} ] }

Allow users read-only access to Amazon WorkDocs resources

The following AWS managed AmazonWorkDocsReadOnlyAccess policy grants an IAM user read-only access to Amazon WorkDocs resources. The policy gives the user access to all of the Amazon WorkDocs Describe operations. Access to the two Amazon EC2 operations are necessary so Amazon WorkDocs

(16)

Troubleshooting

can obtain a list of your VPCs and subnets. Access to the AWS Directory Service DescribeDirectories operation is needed to obtain information about your AWS Directory Service directories.

{

"Version": "2012-10-17", "Statement": [

{

"Effect": "Allow", "Action": [

"workdocs:Describe*", "ds:DescribeDirectories", "ec2:DescribeVpcs", "ec2:DescribeSubnets"

],

"Resource": "*"

} ] }

More Amazon WorkDocs identity-based policy examples

IAM administrators can create additional policies to allow an IAM role or user to access the Amazon WorkDocs API. For more information, see Authentication and access control for administrative applications in the Amazon WorkDocs Developer Guide.

Troubleshooting Amazon WorkDocs identity and access

Use the following information to help you diagnose and ﬁx common issues that you might encounter when working with Amazon WorkDocs and IAM.

Topics

• I am not authorized to perform an action in Amazon WorkDocs (p. 12)

• I am not authorized to perform iam:PassRole (p. 12)

• I want to view my access keys (p. 13)

• I'm an administrator and want to allow others to access Amazon WorkDocs (p. 13)

• I want to allow people outside of my AWS account to access my Amazon WorkDocs resources (p. 13)

I am not authorized to perform an action in Amazon WorkDocs

If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password.

I am not authorized to perform iam:PassRole

If you receive an error that you're not authorized to perform the iam:PassRole action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password. Ask that person to update your policies to allow you to pass a role to Amazon WorkDocs.

Some AWS services allow you to pass an existing role to that service, instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.

(17)

Troubleshooting

The following example error occurs when an IAM user named marymajor tries to use the console to perform an action in Amazon WorkDocs. However, the action requires the service to have permissions granted by a service role. Mary does not have permissions to pass the role to the service.

User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole In this case, Mary asks her administrator to update her policies to allow her to perform the

iam:PassRole action.

I want to view my access keys

After you create your IAM user access keys, you can view your access key ID at any time. However, you can't view your secret access key again. If you lose your secret key, you must create a new access key pair.

Access keys consist of two parts: an access key ID (for example, AKIAIOSFODNN7EXAMPLE) and a secret access key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). Like a user name and password, you must use both the access key ID and secret access key together to authenticate your requests. Manage your access keys as securely as you do your user name and password.

Important

Do not provide your access keys to a third party, even to help ﬁnd your canonical user ID. By doing this, you might give someone permanent access to your account.

When you create an access key pair, you are prompted to save the access key ID and secret access key in a secure location. The secret access key is available only at the time you create it. If you lose your secret access key, you must add new access keys to your IAM user. You can have a maximum of two access keys.

If you already have two, you must delete one key pair before creating a new one. To view instructions, see Managing access keys in the IAM User Guide.

I'm an administrator and want to allow others to access Amazon WorkDocs

To allow others to access Amazon WorkDocs, you must create an IAM entity (user or role) for the person or application that needs access. They will use the credentials for that entity to access AWS. You must then attach a policy to the entity that grants them the correct permissions in Amazon WorkDocs.

To get started right away, see Creating your ﬁrst IAM delegated user and group in the IAM User Guide.

I want to allow people outside of my AWS account to access my Amazon WorkDocs resources

You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.

To learn more, consult the following:

• To learn whether Amazon WorkDocs supports these features, see How Amazon WorkDocs works with IAM (p. 7).

• To learn how to provide access to your resources across AWS accounts that you own, see Providing access to an IAM user in another AWS account that you own in the IAM User Guide.

• To learn how to provide access to your resources to third-party AWS accounts, see Providing access to AWS accounts owned by third parties in the IAM User Guide.

• To learn how to provide access through identity federation, see Providing access to externally authenticated users (identity federation) in the IAM User Guide.

(18)

Logging and monitoring

• To learn the diﬀerence between using roles and resource-based policies for cross-account access, see How IAM roles diﬀer from resource-based policies in the IAM User Guide.

Logging and monitoring in Amazon WorkDocs

Amazon WorkDocs site administrators can view and export the activity feed for an entire site. They can also use AWS CloudTrail to capture events from the Amazon WorkDocs console.

Topics

• Site-wide activity feed (p. 14)

• Logging Amazon WorkDocs API calls using AWS CloudTrail (p. 14)

Site-wide activity feed

Admins can view and export the activity feed for an entire site. To use this feature, you must ﬁrst install Amazon WorkDocs Companion. To install Amazon WorkDocs Companion, see Apps & Integrations for Amazon WorkDocs.

To view and export a site-wide activity feed

1. In the web application, choose Activity.

2. Choose Filter, then move the Site-wide activity slider to turn the ﬁlter on.

3. Select Activity Type ﬁlters and choose Date Modiﬁed settings as needed, then choose Apply.

4. When the filtered activity feed results appear, search by file, folder, or user name to narrow your results. You can also add or remove filters as needed.

5. Choose Export to export the activity feed to .csv and .json ﬁles on your desktop. The system exports the ﬁles to one of the following locations:

• Windows – WorkDocsDownloads folder in your PC's Downloads folder

• macOS – /users/username/WorkDocsDownloads/folder

The exported file reflects any filters that you apply.

Note

Users who are not administrators can view and export the activity feed for their own content only. For more information, see Viewing the Activity Feed in the Amazon WorkDocs User Guide.

Logging Amazon WorkDocs API calls using AWS CloudTrail

Amazon WorkDocs is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Amazon WorkDocs. CloudTrail captures all API calls for Amazon WorkDocs as events, including calls from the Amazon WorkDocs console and from code calls to the Amazon WorkDocs APIs. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Amazon WorkDocs. If you don't conﬁgure a trail, you can still view the most recent events in the CloudTrail console in Event history. Using the information collected by CloudTrail, you can determine the request that was made to Amazon WorkDocs, the IP address from which the request was made, who made the request, when it was made, and additional details.

(19)

CloudTrail logging

To learn more about CloudTrail, see the AWS CloudTrail User Guide.

Amazon WorkDocs information in CloudTrail

CloudTrail is enabled on your AWS account when you create the account. When activity occurs in Amazon WorkDocs, that activity is recorded in a CloudTrail event along with other AWS service events in Event history. You can view, search, and download recent events in your AWS account. For more information, see Viewing events with CloudTrail event history.

For an ongoing record of events in your AWS account, including events for Amazon WorkDocs, create a trail. A trail enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all regions. The trail logs events from all regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs.

For more information, see:

• Overview for creating a trail

• CloudTrail supported services and integrations

• Conﬁguring Amazon SNS notiﬁcations for CloudTrail

• Receiving CloudTrail log ﬁles from multiple Regions and Receiving CloudTrail log ﬁles from multiple accounts

All Amazon WorkDocs actions are logged by CloudTrail and are documented in the Amazon WorkDocs API Reference. For example, calls to the CreateFolder, DeactivateUser and UpdateDocument sections generate entries in the CloudTrail log ﬁles.

Every event or log entry contains information about who generated the request. The identity information helps you determine the following:

• Whether the request was made with root or IAM user credentials.

• Whether the request was made with temporary security credentials for a role or federated user.

• Whether the request was made by another AWS service.

For more information, see the CloudTrail userIdentity element.

Understanding Amazon WorkDocs log ﬁle entries

A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files are not an ordered stack trace of the public API calls, so they do not appear in any specific order.

There are two diﬀerent types of CloudTrail entries that Amazon WorkDocs generates, those from the control plane and those from the data plane. The important diﬀerence between the two is that the user identity for control plane entries is an IAM user. The user identity for data plane entries is the Amazon WorkDocs directory user.

Sensitive information, such as passwords, authentication tokens, ﬁle comments, and ﬁle contents are redacted in the log entries.

The following example shows two CloudTrail log entries for Amazon WorkDocs: the ﬁrst record is for a control plane action and the second is for a data plane action.

{

(20)

Compliance validation

Records : [ {

"eventVersion" : "1.01", "userIdentity" :

{

"type" : "IAMUser", "principalId" : "user_id", "arn" : "user_arn",

"accountId" : "account_id", "accessKeyId" : "access_key_id", "userName" : "user_name"

},

"eventTime" : "event_time",

"eventSource" : "workdocs.amazonaws.com", "eventName" : "RemoveUserFromGroup", "awsRegion" : "region",

"sourceIPAddress" : "ip_address", "userAgent" : "user_agent", "requestParameters" : {

"directoryId" : "directory_id", "userSid" : "user_sid",

"group" : "group"

},

"responseElements" : null, "requestID" : "request_id", "eventID" : "event_id"

}, {

"eventVersion" : "1.01", "userIdentity" :

{

"type" : "Unknown", "principalId" : "user_id", "accountId" : "account_id", "userName" : "user_name"

},

"eventTime" : "event_time",

"eventSource" : "workdocs.amazonaws.com", "eventName" : "LogoutUser",

"awsRegion" : "region",

"sourceIPAddress" : "ip_address", "userAgent" : "user_agent", "requestParameters" : {

"AuthenticationToken" : "**-redacted-**"

},

"responseElements" : null, "requestID" : "request_id", "eventID" : "event_id"

} ]}

Compliance validation for Amazon WorkDocs

Third-party auditors assess the security and compliance of Amazon WorkDocs as part of multiple AWS compliance programs. These compliance programs include SOC, PCI DSS, FedRAMP, HIPAA, ISO 9001, ISO 27001, ISO 27017, and ISO 27018.

For a list of AWS services in scope of speciﬁc compliance programs, see AWS Services in Scope by Compliance Program. For general information, see AWS Compliance Programs.

(21)

Resilience

You can download third-party audit reports using AWS Artifact. For more information, see Downloading reports in AWS Artifact.

Your compliance responsibility when using Amazon WorkDocs is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. AWS provides the following resources to help with compliance:

• Security and Compliance Quick Start Guides – These deployment guides discuss architectural considerations and provide steps for deploying security- and compliance-focused baseline environments on AWS.

• Architecting for HIPAA Security and Compliance Whitepaper – This whitepaper describes how companies can use AWS to create HIPAA-compliant applications.

• AWS Compliance Resources – This collection of workbooks and guides might apply to your industry and location.

• AWS Conﬁg – This AWS service assesses how well your resource conﬁgurations comply with internal practices, industry guidelines, and regulations.

• AWS Security Hub – This AWS service provides a comprehensive view of your security state within AWS that helps you check your compliance with security industry standards and best practices.

Resilience in Amazon WorkDocs

The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption.

Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.

For more information about AWS Regions and Availability Zones, see AWS Global Infrastructure.

Infrastructure security in Amazon WorkDocs

As a managed service, Amazon WorkDocs is protected by the AWS global network security procedures that are described in the Amazon Web Services: Overview of Security Processes whitepaper.

You use AWS published API calls to access Amazon WorkDocs through the network. Clients must support Transport Layer Security (TLS) 1.0 or later. We recommend TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diﬃe-Hellman (DHE) or Elliptic Curve Ephemeral Diﬃe-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes.

Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the AWS Security Token Service (AWS STS) to generate temporary security credentials to sign requests.

(22)

Creating an Amazon WorkDocs site

Getting started with Amazon WorkDocs

Amazon WorkDocs uses a directory to store and manage organization information for your users and their documents. In turn, you attach a directory to a site when you provision that site. When you do, an Amazon WorkDocs feature called Auto activation adds the users in the directory to the site as managed users, meaning they don't need separate credentials to log in to your site, they can share and collaborate on ﬁles, and they have 1 TB of storage.

You no longer need to add and activate users manually, though you still can. You can also change user roles and permissions whenever you need to. For more information about doing that, see Inviting and managing Amazon WorkDocs users (p. 29), later in this guide.

If you need to create directories, you can:

• Create a Simple AD directory.

• Create an AD Connector directory to connect to your on-premises directory.

• Enable Amazon WorkDocs to work with an existing AWS directory.

• Have Amazon WorkDocs create a directory for you.

You can also create a trust relationship between your AD directory and an AWS Managed Microsoft AD Directory.

Note

If you belong to a compliance program such as PCI, FedRAMP, or DoD, you must set up an AWS Managed Microsoft AD Directory to meet compliance requirements. The steps in this section explain how to use an existing Microsoft AD Directory. For information about creating a Microsoft AD Directory, see AWS Managed Microsoft AD in the AWS Directory Service Administration Guide.

Contents

• Creating an Amazon WorkDocs site (p. 18)

• Enabling single sign-on (p. 20)

• Enabling multi-factor authentication (p. 20)

• Promoting a user to administrator (p. 21)

Creating an Amazon WorkDocs site

The steps in the following sections explain how to set up a new Amazon WorkDocs site.

Tasks

• Before you begin (p. 18)

• Creating an Amazon WorkDocs site (p. 19)

Before you begin

You must have the following items before you create an Amazon WorkDocs site.

(23)

Creating an Amazon WorkDocs site

• An AWS account for creating and administering Amazon WorkDocs sites. However, users do not need an AWS account to connect to and use Amazon WorkDocs. For more information, see Prerequisites for Amazon WorkDocs (p. 2).

• If you plan to use Simple AD, you must meet the prerequisites identiﬁed in Simple AD Prerequisites in the AWS Directory Service Administration Guide.

• An AWS Managed Microsoft AD Directory if you belong to a compliance program such as PCI, FedRAMP, or DoD. The steps in this section explain how to use an existing Microsoft AD Directory.

For information about creating a Microsoft AD Directory, see AWS Managed Microsoft AD in the AWS Directory Service Administration Guide.

• Proﬁle information for the administrator, including ﬁrst and last name, and an email address.

Creating an Amazon WorkDocs site

Follow these steps to create an Amazon WorkDocs site in minutes.

To create the Amazon WorkDocs site

1. Open the Amazon WorkDocs console at https://console.aws.amazon.com/zocalo/.

2. On the console's Home page, under Create a WorkDocs site, choose Get Started now.

—OR—

In the navigation pane, choose My sites, and on the Manage your WorkDocs sites page, choose Create a WorkDocs site.

What happens next depends on whether you have a directory.

• If you have a directory, The Select a directory page appears and allows you to choose an existing directory or create a directory.

• If you don't have a directory, the Set up a directory type page appears and allows you to create a Simple AD or AD Connector directory

The following steps explain how to do both tasks.

To use an existing directory

1. Open the Available directories list and choose the directory that you want to use.

2. Choose Enable directory.

To create a directory

1. Repeat steps 1 and 2 above.

At this point, what you do depends on whether you want to use Simple AD or create an AD Connector.

To use Simple AD

a. Choose Simple AD, then choose Next.

The Create Simple AD site page appears.

b. Under Access point, in the Site URL box, enter the URL for the site.

(24)

Enabling single sign-on

c. Under Set WorkDocs administrator, enter the administrator's email address, ﬁrst name, and last name.

d. As needed, complete the options under Directory details and VPC conﬁguration.

e. Choose Create Simple AD site.

To create an AD Connector directory

a. Choose AD Connector, then choose Next.

The Create AD Connector site page appears.

b. Complete all the ﬁelds under Directory details.

c. Under Access point, in the Site URL box, enter your site's URL.

d. As desired, complete the optional ﬁelds under VPC conﬁguration.

e. Choose Create AD Connector site.

Amazon WorkDocs does the following:

• If you chose Set up a VPC on my behalf in step 4 above, Amazon WorkDocs creates a VPC for you. A directory in the VPC stores user and Amazon WorkDocs site information.

• If you used Simple AD, Amazon WorkDocs creates a Directory User and sets that user as an Amazon WorkDocs administrator. If you created an AD Connector directory, Amazon WorkDocs sets the exisitng directory user that you provided as a WorkDocs administrator.

• If you used an existing directory, Amazon WorkDocs prompts you to enter the user name of the Amazon WorkDocs administrator. The user must be a member of the directory.

Note

Amazon WorkDocs doesn't notify users about the new site. You need to communicate the URL to them, and let them know that they don't need a separate login to use the site.

Enabling single sign-on

AWS Directory Service allows users to access Amazon WorkDocs from a computer joined to the same directory with which Amazon WorkDocs is registered, without entering credentials separately. Amazon WorkDocs administrators can enable single sign-on using the AWS Directory Service console. For more information, see Single sign-on in the AWS Directory Service Administration Guide.

After the Amazon WorkDocs administrator enables single sign-on, the Amazon WorkDocs site users might also need to modify their web browser settings to allow single sign-on. For more information, see Single sign-on for IE and Chrome and Single sign-on for Firefox in the AWS Directory Service Administration Guide.

Enabling multi-factor authentication

You use the AWS Directory Services Console at https://console.aws.amazon.com/directoryservicev2/

to enable multi-factor authentication for your AD Connector directory. To enable MFA, you must have an MFA solution that is a Remote authentication dial-in user service (RADIUS) server, or you must have an MFA plugin to a RADIUS server already implemented in your on-premises infrastructure. Your MFA solution should implement One Time Passcodes (OTP) that users obtain from a hardware device or from software running on a device such as a cell phone.

(25)

Promoting a user to administrator

RADIUS is an industry-standard client/server protocol that provides authentication, authorization, and accounting management to enable users to connect to network services. AWS Managed Microsoft AD includes a RADIUS client that connects to the RADIUS server upon which you have implemented your MFA solution. Your RADIUS server validates the username and OTP code. If your RADIUS server successfully validates the user, AWS Managed Microsoft AD then authenticates the user against AD. Upon successful AD authentication, users can then access the AWS application. Communication between the AWS Managed Microsoft AD RADIUS client and your RADIUS server require you to conﬁgure AWS security groups that enable communication over port 1812.

For more information, see Enable multi-factor authentication for AWS Managed Microsoft AD in the AWS Directory Service Administration Guide.

Note

Multi-factor authentication is not available for Simple AD directories.

Promoting a user to administrator

Use the Amazon WorkDocs console to promote a user to administrator. Remember, you can only promote activated users. For more information about activating users, see Editing users (p. 32).

To promote a user to administrator

2. In the navigation pane, choose My sites.

The Manage your WorkDocs Sites page appears.

3. Select the button next to the desired site, choose Actions, then choose Set an administrator.

The Set WorkDocs administrator dialog box appears.

4. In the Username box, enter the user name of the person that you want to promote, then choose Set administrator.

You can also use the Amazon WorkDocs site admin control panel to demote an administrator. For more information, see Editing users (p. 32).

(26)

Setting site administrators

Managing Amazon WorkDocs from the AWS console

You use these tools to manage your Amazon WorkDocs sites:

• The AWS console at https://console.aws.amazon.com/zocalo/.

• The site admin control panel, available to administrators on all Amazon WorkDocs sites.

Each of those tools provides a diﬀerent set of actions, and the topics in this section explain the actions provided by the AWS console. For information about the site admin control panel, see Managing Amazon WorkDocs from the site admin control panel (p. 25).

Setting site administrators

If you're an administrator, you can give users access to the site control panel and the actions that it provides.

To set an administrator

The Manage your WorkDocs sites page appears and displays a list of your sites.

3. Choose the button next to the site for which you want to set an adminitrator.

4. Open the Actions list and choose Set an administrator.

5. In the Username box, enter the new administrator's name, then choose Set administrator.

Resending invitation emails

You can resend an invitation email at any time.

To resend the invitation email

3. Choose the button next to the site for which you want to resend the email.

4. Open the Actions list and choose Resend invitation email.

A success message in a green banner appears at the top of the page.

(27)

Managing multifactor authentication

You can enable multi-factor authentication after you create an Amazon WorkDocs site. For more information about authentication, see Enabling multi-factor authentication (p. 20).

Setting site URLs

Note

If you followed the site creation process in Getting started with Amazon WorkDocs (p. 18), you had to enter a site URL. As a result, Amazon WorkDocs makes the Set site URL command unavailable, because you can only set a URL once. You only follow these steps if you deploy Amazon WorkSpaces and integrate it with Amazon WorkDocs. The Amazon WorkSpaces integration process has you enter a serial number instead of a site URL, so you have to enter a URL after you ﬁnish the integration. For more information about integrating Amazon WorkSpaces and Amazon WorkDocs see Integrate with WorkDocs in the Amazon WorkSpaces User Guide.

To set a site URL

3. Select the site that you integrated with Amazon WorkSpaces. The URL contains the directory ID of your Amazon WorkSpaces instance, such as https://{directory_id}.awsapps.com.

4. Choose the button next to that URL, open the Actions list, and choose Set site URL.

The Set site URL dialog box appears.

5. In the Site URL box, enter the URL for the site, then choose Set site URL.

6. On the Manage your WorkDocs sites page, choose Refresh to see the new URL.

Managing notiﬁcations

Notifications allow IAM users or roles to call the CreateNotificationSubscription API, which you can use to set your own endpoint for processing the SNS messages that WorkDocs sends. For more information about notifications, see Setting up notifications for an IAM user or role in the Amazon WorkDocs Developer Guide.

You can create and delete notiﬁcations, and the following steps explain how to do both tasks.

To create a notiﬁcation

3. Choose the button next to the desired site.

4. Open the Actions list and choose Manage notiﬁcations.

(28)

Deleting a site

To delete a notiﬁcation

3. Choose the button next to the site for which you want to set an adminitrator.

4. Open the Actions list and choose Set an administrator.

Deleting a site

Use the Amazon WorkDocs console to delete a site.

Warning

You lose all ﬁles when you delete a site. Delete a site only if you are sure that this information is no longer needed.

To delete a site

2. In the navigation bar, choose My sites.

The Manage your WorkDocs sites page appears.

3. Choose the button next to the site that you want to delete, then choose Delete.

The Delete site URL dialog box appears.

4. Optionally, choose Also delete the user directory.

Important

If you don't provide your own directory for Amazon WorkDocs, we create one for you.

When you delete the Amazon WorkDocs site, you are charged for the directory that we create unless you delete that directory or use it for another AWS application. For pricing information, see AWS Directory Service Pricing.

5. In the Site URL box, enter the site URL, then choose Delete.

The site is immediately deleted and is no longer available.

(29)

Preferred language settings

Managing Amazon WorkDocs from the site admin control panel

You use these tools to manage your Amazon WorkDocs sites:

• The site admin control panel, available to administrators on all Amazon WorkDocs sites, and described in the following topics.

• The AWS console at https://console.aws.amazon.com/zocalo/.

Each of those tools provides a diﬀerent set of actions. The topics in this section explain the actions provided by the site admin control panel. For information about the tasks available in the console, see Managing Amazon WorkDocs from the AWS console (p. 22).

Preferred language settings

You can specify the language for email notiﬁcations.

To change language settings

1. Under My Account, choose Open admin control panel.

2. For Preferred Language Settings, choose your preferred language.

Hancom Online Editing and Oﬃce Online

Enable or disable Hancom Online Editing and Oﬃce Online settings from the Admin control panel. For more information, see Enabling collaborative editing (p. 39).

Storage

Specify the amount of storage that new users receive.

To change storage settings

2. For Storage, choose Change.

3. In the Storage Limit dialog box, choose whether to give new users unlimited or limited storage.

4. Choose Save Changes.

Changing the storage setting aﬀects only users that are added after the setting is changed. It does not change the amount of storage allocated to existing users. To change the storage limit for an existing user, see Editing users (p. 32).

(30)

IP allow list

Amazon WorkDocs site administrators can add IP Allow List settings to restrict site access to an allowed range of IP addresses. You can add up to 32 IP Allow List settings per site.

Note

The IP Allow List currently works for IPv4 addresses only. IP address denylisting is not currently supported.

To add an IP range to the IP Allow List

2. For IP Allow List, choose Change.

3. For Enter CIDR value, enter the Classless Inter-Domain Routing (CIDR) block for the IP address ranges, and choose Add.

• To allow access from a single IP address, specify /32 as the CIDR preﬁx.

4. Choose Save Changes.

5. Users who connect to your site from the IP addresses on the IP Allow List are allowed access.

Users who attempt to connect to your site from unauthorized IP addresses receive an unauthorized response.

Warning

If you enter a CIDR value that blocks you from using your current IP address to access the site, a warning message appears. If you choose to continue with the current CIDR value, you will be blocked from accessing the site with your current IP address. This action can only be reversed by contacting AWS Support.

Security – public share settings

In the Admin control panel, under Security, choose Who should be allowed to create publicly shareable links? to specify which users are allowed to send ﬁle view links to people outside of the organization. Choose from the following settings:

No public sharing

Users cannot send view links to anyone outside the organization.

All managed users can share publicly

All users can send view links to anyone outside the organization.

Only Power users can share publicly

Only Power users can send view links to people outside the organization.

Security – invitation settings

Choose from the following settings for Who should be allowed to join your WorkDocs site?.

Users can invite people from anywhere by sharing ﬁles or folders with them

Users can invite people from anywhere outside the organization by sharing ﬁles or folders with them.

Amazon WorkDocs

Amazon WorkDocs

Administration Guide

Amazon WorkDocs: Administration Guide

Table of Contents

What is Amazon WorkDocs?

Accessing Amazon WorkDocs

Pricing

How to get started

Prerequisites for Amazon WorkDocs

Sign up for AWS

To sign up for an AWS account

Create IAM users and groups (recommended)

Security in Amazon WorkDocs

Identity and access management for Amazon WorkDocs

Audience

Authenticating with identities

AWS account root user

IAM users and groups

IAM roles

Managing access using policies

Identity-based policies

Resource-based policies

Access control lists

Other policy types

Note

Multiple policy types

How Amazon WorkDocs works with IAM

Amazon WorkDocs identity-based policies

Actions

Note

Resources

Condition keys

Examples

Amazon WorkDocs resource-based policies

Authorization based on Amazon WorkDocs tags

Amazon WorkDocs IAM roles

Using temporary credentials with Amazon WorkDocs

Service-linked roles

Service roles

Amazon WorkDocs identity-based policy examples

Note

Policy best practices

Using the Amazon WorkDocs console

Allow users to view their own permissions

Allow users read-only access to Amazon WorkDocs resources

More Amazon WorkDocs identity-based policy examples

Troubleshooting Amazon WorkDocs identity and access

I am not authorized to perform an action in Amazon WorkDocs

I am not authorized to perform iam:PassRole

I want to view my access keys

Important

I'm an administrator and want to allow others to access Amazon WorkDocs

I want to allow people outside of my AWS account to access my Amazon WorkDocs resources

Logging and monitoring in Amazon WorkDocs

Site-wide activity feed

To view and export a site-wide activity feed

Note

Logging Amazon WorkDocs API calls using AWS CloudTrail

Amazon WorkDocs information in CloudTrail

Understanding Amazon WorkDocs log ﬁle entries

Compliance validation for Amazon WorkDocs

Resilience in Amazon WorkDocs

Infrastructure security in Amazon WorkDocs

Getting started with Amazon WorkDocs

Note

Creating an Amazon WorkDocs site

Before you begin

Creating an Amazon WorkDocs site

To create the Amazon WorkDocs site

To use an existing directory

To create a directory

To use Simple AD

To create an AD Connector directory

Note

Enabling single sign-on

Enabling multi-factor authentication

Note

Promoting a user to administrator

To promote a user to administrator