This guide explains how Cloudaware capabilities should be deployed to improve cloud security, mitigate risks associated with operating cloud-based computing infrastructure, address compliance and change management. |
This guide is for:
Security Engineers
Cloudaware Engineers
Chief Security Officers
Compliance Officers
Cloud Engineers
Cloud Operations Teams
Cloudaware is a SaaS-based cloud management application. The application runs entirely in Force.com container architecture, also known as App Cloud. This allows Cloudaware to delegate many scalability and security challenges to SFDC.
Cloudaware leverages the powerful, scalable, and secure Force.com platform for application development and deployment. The Force.com platform delivers a complete technology stack from the infrastructure level to the user interface. Delivery of the technology stack allows Cloudaware to focus on assembling, building and instantly deploying application solutions to meet customer needs.
The Force.com platform enables Cloudaware to implement business logic with workflow rules, approval processes, and custom code. Cloudaware can store structured data, support Web browsers, integrate with other applications, perform reporting and analytics, and scale up or down — all with sub-second response time, high availability, and security customers require to run business applications.
Development and deployment of Cloudaware both take place in the Force.com App Cloud. The Force.com platform provides the capabilities needed for robust enterprise application development through a combination of clicks, components, and code. The platform’s functionality makes Cloudaware developers more productive, allowing them to create application capabilities from simple declarations of attributes through pre-built capabilities to extend them to a fully flexible application development environment.
The entire Force.com platform reporting and analytics system is automatically built into every Cloudaware module. This integrated functionality lets customers mine their data store for additional value. In addition to using Cloudaware, customers can develop their own custom websites using Force.com platform sites. Force.com platform sites extend the capabilities of the Force.com platform to allow customers to share business data and applications on the Force.com platform to external users and websites. Portals and/or Communities can be used to provide identification and authentication capabilities to Force.com platform sites. Websites and web applications that are run using Force.com platform sites gain all the benefits of the proven security, reliability, and scalability of App Cloud trusted global infrastructure.
To enhance the collaboration capabilities provided by Cloudaware, Salesforce provides customers the capability to collaborate with customers or partners via Salesforce Portals or Communities.
App Cloud brings together all the tools and services that have made us the world's #1 enterprise cloud platform. With a unified ecosystem for building, managing, buying, and optimizing apps — all built on Salesforce's trusted cloud infrastructure — App Cloud empowers CIOs with everything they need to quickly build apps in any language, for any device, and manage them all in a single enterprise cloud environment.
For additional information about App Cloud, click here
Force.com protects Customer Data by ensuring that only authorized users can access it. Cloudaware Administrators assign data security rules that determine which data users can access. Sharing models define company-wide defaults and data access based on a role hierarchy. All users and application-level security are defined and maintained by the Cloudaware administrator, and not by Cloudaware.
When a new Cloudaware Org is provisioned, a Cloudaware System Administrator for the Org is established. The Cloudaware System Administrator is responsible for setting up the Cloudaware Org and provisioning other users on the Org. Cloudaware uses TrialForce API to set up the Cloudaware System Administrator by entering the individual’s first name, last name, and email address (username) and activating the Org.
Once the Org is active, the Cloudaware application will automatically generate an email to the Cloudaware System Administrator’s email address. This email contains a link for the individual to click to set up his/her password for the first time. Once the Cloudaware System Administrator is authenticated, he/she can begin setting up the Org including any security parameters, configuring single sign-on (SSO), and provisioning other users.
The Cloudaware System Administrator can provision other administrators (delegated administrators), end users from the customer, or external users (partners, third parties, citizens).
The Cloudaware System Administrator is responsible for the primary system capabilities and security configuration settings for the entire organization. The Cloudaware System Administrator can delegate some administrative activities by establishing additional profiles and roles with equivalent capabilities.
The organization configuration settings, including most security controls, are configured on the Force.com platform and apply to all applications purchased and installed or developed by the organization.
An organization's sharing model sets the default access that users have to each other's data. There are four sharing models: Private, Public Read Only, Public Read/Write, and Public Read/Write/Transfer. There are also several sharing model elements: Profiles, Roles, Hierarchy, Record Types, Page Layouts, and Field Level Security.
To learn more about Force.com sharing models, click here
For primary data storage, Cloudaware leverages the Force.com built-in capability to apply field-level encryption, to encrypt custom fields containing sensitive data within their Cloudaware Org. The feature is available to customers by default, but customers must choose to implement this feature for their Cloudaware Org. Field-level encryption allows customers to encrypt custom fields containing letters, numbers, and symbols. The fields are encrypted with AES-128 and are FIPS 140-2 validated (certificate #1837). Only users with the "View Encrypted Data" permission can view the content of the encrypted custom fields. To utilize field-level encryption capabilities, customers can create a new custom field and choose the data type as 'Text (Encrypted)'. This will configure a field that can contain any combination of letters, numbers, and symbols and store them in encrypted form. Customers can specify the "mask type" and "mask character" for any encrypted custom fields.
Existing custom fields cannot be converted into encrypted fields nor can encrypted fields be converted into another data type. To encrypt the values of an existing (unencrypted) field, export the data, create an encrypted custom field to store that data, and import that data into the new encrypted field. Data stored within a customer’s Cloudaware Org using field-level encryption is encrypted with a FIPS 140-2 validated library (certificate #1837).
Cloud account credentials, for example, AWS Access Keys and Secret Keys, are encrypted using field-level encryption by default.
Delegated authentication enables customers to integrate Cloudaware with a customer-selected authentication method including Lightweight Directory Access Protocol (LDAP) server, or performs single sign-on by authenticating using a token instead of a password. Delegated authentication is managed by a customer at the profile level, allowing some users to use delegated authentication, while other users continue to use their Force.com managed password. For an administrator, customers may choose to allow both tokens and passwords (backup mechanism), so that a user could still log in to Cloudaware through the login page in the event of an emergency.
Configuring Cloudaware for single sign-on, customers allow a delegated authentication authority. When users first log in to their network environment, they are initially authenticated by this authority. When attempting to log in to subsequent protected applications, the user requests a token from a token generator instead of passing a username and password to the application. The received token is given to the application verifying that the token correctly identifies the user and then allows the user access to the application.
Using delegated authentication, Cloudaware does not validate passwords but instead uses an external Web service to validate user credentials. When a user attempts to log in, the platform checks the user's profile to see if they are enabled for SSO. If so, it makes a Web services call to the endpoint specified for the organization (environment) asking it to validate the username and password. The Web service checks the credentials against an identity store (for example, LDAP or OpenID) and either returns "true" or "false". If true, the user is granted access to the application and proceeds normally. If false, the user is informed that their credentials are invalid.
The Force.com platform is pre-configured to provide customers with a set of pre-defined audit reports and capabilities. In addition to the standard logging capabilities, customers have the ability to develop custom code for their organization in order to implement custom logging configurations. The Force.com platform produces audit records for customers that contain sufficient information to, at a minimum, establish what type of event occurred, when (date and time) the event occurred, where the event occurred, the source of the event, the outcome (success or failure) of the event, and the identity of any user/subject associated with the event.
The standard auditing reports include Setup Audit Trail, Login History, Activations, Field History Tracking, Record Modification Fields, and Monitoring reports. The auditing reports capture information specific to a customer’s Org in Salesforce and will include log events for any portals and communities associated with the Org.
For the customer-facing audit logs, the Setup Audit Trail and Login History audit records are available to a customer's administrators for generation for at least 180 days. Customers can download the Setup Audit Trail and Login History audit reports as .csv files if they would like to retain reports longer than 180 days.
The Field History Tracking audit records are available for 18 months. Activations include the current log of activated login IPs and Activated Client browsers. The list of current Activations is dynamically updated. Record Modification Fields include a user who created the record and who last modified the record. Monitoring reports are intended as a method to view specific audit content related to the operation and development of a customer’s Cloudaware Org. Monitoring reports include reports on file imports organized by user, API usage alerts, email logs, workflow queue, scheduled jobs, and user’s debug logs.
In addition to the standard reports, customizable reports are available from the Reports tab to administrators and users. Customers can save custom reports generated through the Reports tab to their personal reports folder in Cloudaware in order to retain data indefinitely. To support forensics or after-the-fact investigations, Salesforce makes audit logs directly available to customers via the Force.com platform.
The logging information that is available to customers is stored within the database supporting the customer’s Cloudaware Org. In addition to the standard customer facing audit reports available, Salesforce offers an Event Monitoring feature that can provide more detailed application log files for customers to download via an API extract. Internal infrastructure logs are collected by various monitoring tools for activities on the systems that host the Cloudaware application.
To learn more about Force.com auditing capabilities, click here
Cloudaware claims no right to Customer Data or any non-Cloudaware application or program code other than a license necessary to provide the Cloudaware services in accordance with the applicable subscription agreement. Customer Data is electronic data and information submitted to Cloudaware by customers or gathered by Cloudaware using API collectors.
Cloudaware customers are responsible for complying with e-discovery requirements in their use of Cloudaware. If a Cloudaware customer must preserve their Customer Data, they may schedule a weekly export of data or copy to a sandbox account. Customers can export their Org data using the Org Export Tool or the DB Replica API and save the data locally or request exports of their data in .csv format from Cloudaware’s Support Department. Force.com also supports data replication, which allows customers to store and maintain a local separate copy of their organization's Cloudaware data including the Metadata (data about data) for specialized uses, including data warehousing, data mining, custom reporting, analytics, and integration with other applications.
Data replication provides customers with local control and the ability to run large or ad hoc analytical queries across the entire dataset. In addition to allowing customers to export their data, Force.com conducts extensive application logging and monitoring available to customers via the Force.com platform.
The Force.com platform also maintains application event log files that are a superset of the logs used for troubleshooting. These logs provide clickstream level data about customer actions on their Cloudaware Org. Detailed application logs can be used for forensics investigations by customers. These logs are stored for a minimum of 1 year and are available for a fee (standard consulting fees).
When a customer ends their contract with Cloudaware, the customer should export their data and retain it locally to meet data retention requirements. Upon contract termination, the data on the disk is locked for 30 days and inaccessible to the customer. After 30 days, data is permanently deleted. Customers have the option of transferring ownership of the underlying Salesforce organization to a third party.
The setup features discussed below apply to the Force.com platform and Cloudaware, as well as any customer-built applications hosted on Force.com. Administrators can configure the security features available for their implementation of Cloudaware using the setup features discussed below.
Cloudaware System Administrators, and personnel designated by the Cloudaware System Administrator, have access permissions that allow a user to access the Administration Setup functionality under the Setup tab.
The Administration Setup allows Cloudaware System Administrators to manage users, apps, the company profile, security controls, domain management, communication templates, translation, data management, mobile administration, desktop administration, email administration, and integration with Google Apps.
Administrators can use the Administration Setup functionality to configure the organization’s security controls and various system capabilities. The examples of security settings that can be configured are authentication mechanism, password parameters, IP address restrictions, and time restrictions.
Customer administrators can also contact Cloudaware Technical (Customer) Support to receive additional assistance with appropriately configuring security controls and system capabilities for the organization. Depending on the level of support required, the customer can grant access to the Cloudaware Technical Support personnel for a set period of time, allowing them to authenticate to the customer organization for troubleshooting purposes. During a trial period, Cloudaware Technical Support has access to the customer Org by default.
By granting this access, the customer should be aware that Cloudaware Technical Support personnel can view the organizational settings and potentially view customer-generated data that an individual granting the access has access to.
Cloudaware System Administrators, and personnel delegated by the Cloudaware System Administrator, have access permissions that allow a user to access the App Setup. The App Setup contains options to customize a Cloudaware Org, and build, deploy, and manage applications. The App Setup allows authorized users to customize standard tabs and types of records; create applications and customize the customer’s Cloudaware Org using point-and-click tools, including managing call center settings; access and use Salesforce provided development tools to create applications and customize the customer’s Cloudaware Org; monitor the deployment of setup configurations; view installed packages from the AppExchange; and control when critical updates are enabled on the organization. These capabilities provide customers with application customization and development capabilities that are the foundation of the Salesforce PaaS and SaaS offerings.
All users have access to the Personal Setup/My Settings options. Personal Setup/My Settings contains setup and customization options to help users personalize their organization’s implementation of Cloudaware. Within Personal Setup/My Settings users can edit their user information; view their login history; change their password; reset their security token; manage personal groups; change their display, grant login access; share calendars; set activity reminders; set preferences for automatic selection of default record types; manage email settings; import information into the application; configure desktop integration; manage chatter settings. Some capabilities under the Personal Setup/My Settings page, including password changes and desktop integration, may be restricted by customer policy and organization-wide configuration settings.
The Force.com platform and Cloudaware offer management, integration, and development tools and services, including SSO, APIs, and application coding languages that can be used to automate administration and system functionality. The following is a list of the primary tools and services that are available for customers:
Single sign-on, Federated authentication using Security Assertion Markup Language (SAML): Allows customers to send authentication and authorization data between affiliated but unrelated Web services. Enables customers to sign on to Cloudaware from a client application. When federated authentication is enabled, Salesforce does not validate a user's password. Instead, Salesforce verifies an assertion in the HTTP POST request, and allows single sign-on if the assertion is true. Federated authentication using SAML is available by default.
Single sign-on, Delegated authentication: Enables customers to integrate Cloudaware with a customer-selected authentication method including Lightweight Directory Access Protocol (LDAP) server, or performs single sign-on by authenticating using a token instead of a password. Delegated authentication is managed by the customer at the Profile level, allowing some users to use delegated authentication, while other users continue to use their Salesforce-managed password. When delegated authentication is enabled, Salesforce does not validate a user's password. Instead, Salesforce makes a Web services call to the customer organization to establish authentication credentials for the user. This feature must be requested by the customer and enabled by Cloudaware.
Single sign-on, External Authentication Providers: Enables customer users to log into their Cloudaware Org using their login credentials from an external service provider. In order to implement Authentication Providers for single sign-on customers must first configure the service provider's website, create a registration handler using Apex, and define the authentication provider for their organization. Any service provider that supports the OpenID Connect protocol is supported. Customers implementing IP Range restrictions for user logins and/or session locking, are not able to use the Authentication Providers option for single sign-on.
External Data API: Used to upload external data files to Cloudaware. The External Data API can upload .csv, .gz, or .zip files and edit existing datasets by uploading a new .csv file. Using the External Data API provides options to overwrite all records, append records, update records, and delete records.
SOAP API, previously known as the Web Services API: Used to create, retrieve, update, or delete records in the Force.com platform from any external system that supports SOAP-based Web services, including Java, .NET, or PHP client applications. With more than 20 different calls, the API also allows users to maintain passwords, perform searches, retrieve metadata information about objects and more.
Metadata API: Used to retrieve, deploy, create, update or delete customization information, including custom object definitions and page layouts (XML representations), for an organization. The most common usage is to migrate changes from a sandbox or testing organization to a production organization. Metadata API is intended for managing customizations and for building tools that can manage the metadata model, not the data itself.
Bulk API: Provides programmatic access to allow users to quickly load their organization's data into Cloudaware. The Bulk API allows the user to insert, update, upsert or delete a large number of records asynchronously.
Chatter REST API: Used to integrate mobile apps, intranet sites, and third-party Web applications with Chatter. The Chatter REST API provides resources for feeds, comments, likes, users, groups, private messages, and recommendations. The Chatter REST API is on by default in all organizations and editions that have Chatter.
Chatter in Apex: Exposes many Chatter API resources as objects in Apex and can be used to build Chatter integrations and custom UI on Force.com without making HTTP callouts to the Chatter API. Tooling API provides SOAP and REST interfaces that allow customers to build custom development tools for Force.com platform applications.
Streaming API: Allows customers to expose a near real-time stream of data from Force.com platform. Administrators can create topics, to which applications can subscribe, receiving asynchronous notifications of changes to data on Force.com platform.
REST API: Search Scope and Order. The scope and order call in the REST API returns an ordered list of objects in the default global search scope of a logged-in user. The global search keeps track of which objects the user interacts with and how often and arranges the search results accordingly. The objects used most frequently appear at the top of the list.
Apex REST API: Enables developers to create their own REST-based web services using Apex. It has all of the advantages of the REST architecture, provides the ability to define custom logic, and includes automatic argument/object mapping.
Apex SOAP API: Apex SOAP Web services allow an external application to invoke Apex methods through SOAP Web services. Apex callouts enable Apex to invoke external Web or HTTP services.
Apex: A programming language supported on the Force.com platform that allows users to perform functions including: creating Web and email services; performing complex validation over multiple objects; creating complex business processes that are not supported by workflow; creating custom transactional logic (logic that occurs over the entire transaction, not just with a single record or object); and attaching custom logic to another operation, including saving a record, so that it occurs whenever the operation is executed.
Visualforce: A tag-based markup language that gives developers a more powerful way of building applications and customizing the user interface. With Visualforce, customers can build wizards and other multi-step processes, create custom flow control through an application, and define navigation patterns and data-specific rules for optimal, efficient application interaction.
Salesforce Object Query Language (SOQL): Used to construct simple but powerful query strings. The SOQL can be used in query calls, in Apex statements, in Visualforce controllers and getter methods, and in the Schema Explorer of the Eclipse Toolkit. Similar to the SELECT command in Structured Query Language (SQL), SOQL allows users to specify the source object (e.g. Account), a list of fields to retrieve, and conditions for selecting rows in the source object. Creates new objects and updates existing objects; uses a custom field to determine the presence of existing objects. Upsert is a merging of the words insert and update. This call is available for objects if the object has an external ID field or a field with the idLookup field property. On custom objects, this call uses an indexed custom field called an external ID to determine whether to create a new object or update an existing object. On standard objects, this call can use the name of any field with the idLookup field property instead of the external ID.
Salesforce Object Search Language (SOSL): Used to construct searches for text, email, and phone fields for multiple objects simultaneously. The SOQL can be used in query calls, in Apex statements, in Visualforce controllers and getter methods, and in the Schema Explorer of the Eclipse Toolkit. SOSL allows customers to specify the following for source objects: text expression; scope of fields to search; list of objects and fields to retrieve; and conditions for selecting rows in the source objects.