Secure Salesforce: Org Access Controls
2 likes1,466 views
The document discusses access control measures for securing Salesforce organizations, including authentication protocols, session management, and connected apps. It emphasizes the importance of strong passwords, two-factor authentication, and IP restrictions to prevent data breaches. Additionally, it covers features such as single sign-on, session policies, and egress control to enhance overall security within the Salesforce platform.
Secure Salesforce: Org Access Controls
- 1. Secure Salesforce: Organization Access Controls Mikel Otaegi Principal Security Engineer Jorge L Cáceres Senior Platform Security Engineer
- 2. Safe Harbor Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward- looking statements.
- 3. Access Controls To Your Organization • We will be covering high level administrator-oriented topics on securing access to your Salesforce Organization
- 4. Access Controls To Your Organization Specific features that we will cover include: – Locking The Gates With Strong Authentication • Password Policies • Two Factor Authentication • IP Restrictions • Single Sign-On – Keeping The Bad Guys Out With Secure Sessions • Session Settings • Activations • Session Information • Expire All Passwords – Connected Apps • OAuth Policies • Session Policies • Remote Site Settings – Protecting Assets With Egress Control • File Upload and Download Security • CORS (Cross-Origin Resource Sharing)
- 5. Locking The Gates With Strong Authentication PHOTO: Ryan Green
- 6. Who knows what the most common cause of data breaches is?
- 7. Locking The Gates: Password Policies
- 8. Locking The Gates: Password Policies 1. Weak And Stolen Credentials, a.k.a. Passwords Hacking remains the single biggest cause of attacks don't depend on finding vulnerabilities in the application or network protocol to tunnel through. For years, experts have warned about the risks of relying on weak credentials to restrict who has access to the data, and this is still a problem. About 76% of network intrusions involved weak credentials, according to Verizon's data breach report. Authentication-based attacks, which includes guessing passwords, cracking using specific tools or trying out passwords from other sites on the target system, factored into about four of every five breaches that was classified as a hacking incident in 2012, Verizon says. (http://twimgs.com/darkreading/attacks-breaches/S6980513breachcauses.pdf)
- 9. Who knows what the most common used password is in America?
- 10. Locking The Gates: Password Policies
- 11. Locking The Gates: Two Factor Authentication Stolen passwords played a role in 48% of the data breaches that involved hacking, Verizon found. This could have been accomplished by using stolen password lists from previous data breaches, keylogging malware or phishing attacks. If that number isn't eye-popping enough, Verizon estimated that 80% of data breaches would have been stopped or forced to change tactics if a "suitable replacement" (such as multifactor authentication) to passwords had been used.
- 12. Locking The Gates: Two Factor Authentication What is Two Factor Authentication? Two factor authentication is using more than one of the following to login or process a transaction • Something you know (account details or passwords) • Something you have (tokens or mobile phones) • Something you are (biometrics)
- 13. Locking The Gates: Two Factor Authentication Two Factor Authentication With Salesforce • Two Factor Authentication introduces the ability to use an App to generate OTPs • Policies may be set to force two-factor authentication on login • Session Level policies allow you to block specific actions, or “step-up” authentication
- 14. Locking The Gates: Two Factor Authentication
- 15. Locking The Gates: Two Factor Authentication
- 16. Locking The Gates: Two Factor Authentication
- 17. Locking The Gates: Two Factor Authentication
- 18. Locking The Gates: Two Factor Authentication
- 19. Locking The Gates: Two Factor Authentication
- 20. Locking The Gates: IP Restrictions Trusted Login IP Ranges The salesforce platform allows administrators to define IP ranges that are trusted. Users who login from defined IP ranges are trusted and the login operation proceeds normally. It is important to understand that this only covers login operations. If a user already has a valid session id, they could make requests from IPs not in the trusted range unless you have specified the option to lock sessions to originating IP which we will cover later. There are two ways Trusted IP ranges can be defined, and each has unique security features: – Organization level Trusted Login IP ranges – Profile level Trusted Login IP ranges
- 21. Locking The Gates: IP Restrictions Organization Level Trusted Login IP Ranges Administrators define a list of IP addresses from which users can login without receiving a login challenge for verification of their identity, such as a code sent to their mobile phone. The main security behavior here is that login is not completely blocked. If the user succesfully completes the login challenge, they can proceed. The requirements and behavior is different based on entry point of login: UI/Browser, or API. UI/browser login: As defined above. User must go through a login challenge if coming from an IP outside the Organization Trusted range. After a succesful challenge, the user's client browser is now trusted and can login from any ip address without being challenged. This is accomplished with a unique cookie set on the client's browser. If the client's browser cookie is cleared, a login challenge will be required on login from an IP outside the Trusted range. This in effect turns the Trusted Login IP range into a type of Trusted client feature.
- 22. Locking The Gates: IP Restrictions Organization Level Trusted Login IP Ranges API login: In order to login from an IP outside the Organization Trusted range, the user must provide a security token appended to their password. Users can obtain their security token by changing their password or resetting their security token via the Salesforce user interface. Unlike the UI login, API login always requires the security token.
- 23. Locking The Gates: IP Restrictions
- 24. Locking The Gates: IP Restrictions Profile Level Trusted Login IP Ranges • Administrators define a list of IP addresses from which users can log in. • This list is defined per profile. • The main security feature is that login is completely blocked if coming from an untrusted IP.
- 25. Locking The Gates: IP Restrictions
- 26. Locking The Gates: Single Sign-On Single Sign-On Options With Salesforce • Delegated Authentication (not available by default, must submit a support case) • SAML Federated Authentication
- 27. Locking The Gates: Single Sign-On SAML Federated Authentication ● Federated authentication is a form of authentication (commonly referred to as single sign-on or SSO) that allows the portability of identity information to multiple services without the need for redundant identity management in each service. ● This type of authentication is advantageous for the user because they can remember one password and gain access to many resources. ● This type of authentication is also advantageous from a management perspective because it centralizes identity information and can provide a single location to disable access.
- 28. Locking The Gates: Single Sign-On Understanding SAML ● In Salesforce, federated authentication employs SAML (Security Assertion Markup Language) which provides a secure, XML-based solution for exchanging user security information between two parties. o There are 2 versions of SAML supported by Salesforce, 1.1 and 2.0. Version 2.0 is the default because it includes many more features and allows for multiple configurations within Salesforce. ● The SAML assertion is the message sent by the identity service that the recipient uses for authentication. It provides several strong security features: o All the details of the authentication request are contained in the SAML assertion.
- 29. Locking The Gates: Single Sign-On
- 30. Locking The Gates: Single Sign-On
- 31. Keeping The Bad Guys Out With Secured Sessions Picture licensed under a Creative Commons Attribution Share-Alike 3.0 License
- 32. Keeping The Bad Guys Out: Introduction Introduction Administrator functions to maintain secure sessions ● Session Settings Set the session security and session expiration timeout for your organization. ● Activations Maintain the list of IP addresses representing the device IP addresses that have been activated by a user. ● Session Management The View information about or delete active user sessions. ● Expire All Passwords Use to expire the passwords for all of the users in your
- 33. Keeping The Bad Guys Out: Session Settings
- 34. Keeping The Bad Guys Out: Activations
- 35. Keeping The Bad Guys Out: Session Management
- 36. Keeping The Bad Guys Out: Expire All Passwords
- 37. Connected Apps: Introduction • A connected app integrates an application with Salesforce using APIs. • The administrators can set various security policies and have explicit control over who may use the connected app. • Two deployment modes: – The app is created and used in the same organization. – The app is created in one organization and installed on other organizations.
- 38. Connected Apps: Basic Information • The administrators can set various security policies and have explicit control over who may use the connected app: • Via the connected app configuration, administrators can install the connected app, enable SAML, use profiles, permission sets, and IP range restrictions to control which users can access the application • Connected apps use SAML and OAuth to authenticate, provide Single Sign-On, and provide tokens for use with Salesforce APIs. • Connected apps can be added to managed packages, only.
- 39. Connected Apps: OAuth Basics Supported OAuth flows: ● Web Server flow ● User-Agent flow ● JWT Bearer Token Flow ● SAML Bearer Assertion Flow ● SAML Assertion Flow ● Username and Password
- 40. OAuth Policies Make sure to always follow the principle of least privilege while defining this scope. Only provide the minimum access required for the application use case.
- 41. OAuth Policies
- 43. Connected Apps: Session Policies
- 45. Secure Salesforce at Dreamforce 2015 10 DevZone Talks and 2 Lighting Zone Talks covering all aspects of Security on the Salesforce Platform Visit our booth in the DevZone with any security questions Check out the schedule and details at http://bit.ly/DF15Sec Admin-related security questions? Join us for coffee in the Admin Zone Security Cafe
- 46. Secure Salesforce – Thursday Morning Org Access Controls Jorge Caceres and Mikel Otaegi 9:30am in Moscone West 2007 Secret Storage in your Salesforce Instance Kyle Tobener and Ian Goldsmith 9:30am in Moscone West 2011 External App Integration Astha Singhal and Chris Vinecombe 12:00pm in Moscone West 2010
- 47. Secure Salesforce – Thursday Afternoon Hardened Apps with the Mobile SDK Martin Vigo and Maxwell Feldman 2:30pm in Moscone West 2008 Code Scanning with Checkmarx Robert Sussland and Gideon Kreiner 3:30pm in Moscone West 2011 Lightning Components Best Practices Robert Sussland and Sergey Gorbaty 4:45pm in Moscone West 2007 Common Secure Coding Mistakes Rachel Black and Alejandro Raigon Munoz 5:00pm in Moscone West 2006
- 48. Secure Salesforce – Friday Chimera: External Integration Security Tim Bach and Travis Safford 10:00am in Moscone West 2009
- 49. Q&A
- 51. Additional Resources • Secure Coding Guidelines - https://developer.salesforce.com/page/Secure_Coding_Storing_Secrets • Intro to Managed Packages - https://developer.salesforce.com/page/An_Introduction_to_Packaging • Salesforce StackExchange - http://salesforce.stackexchange.com/questions/tagged/security • Developer.Salesforce.com Security Forum - https://developer.salesforce.com/forums (full link hidden) • Security Office Hours (Partners) - http://security.force.com/security/contact/ohours • Security Implementation Guide - https://developer.salesforce.com/././securityImplGuide/ (full link hidden)
- 52. Additional Security Features For Access Control
- 53. Locking The Gates: Single Sign-On Delegated Authentication Delegated authentication is a form of authentication that forwards the username and password from Salesforce via web-service callout to an admin specified endpoint that can verify and authenticate the user. ● To build the external webservice, a WSDL is available in the Salesforce setup menu. Navigate to Setup - > Build -> Develop -> Api and click “Delegated Authentication WSDL” ● Users are enabled for delegated authentication via the “Single Sign-On Enabled” profile permission.
- 54. Locking The Gates: Single Sign-On
- 55. Keeping The Bad Guys Out: Activations
- 56. Locking The Gates: Single Sign-On
- 57. Connected Apps: Session Policies Features that use session level security: – Reports and dashboard in Salesforce1 Reporting – Connected apps. You can specify an action to take if the session used to access the resource is not High Assurance. • Block — Blocks access to the resource by showing an insufficient privileges error. • Raise session level — Redirects the user to log in based on the login method associated with High Assurance security level. When the user completes the login flow successfully, the user can access the resource. For reports and dashboards, you can apply this action when users access reports or dashboards, or just when they export and print reports.
- 58. Remote Site Settings Before any Visualforce page, Apex callout, or JavaScript code using XmlHttpRequest in an s-control or custom button can call an external site, that site must be registered in the Remote Site Settings page, or the call will fail. For security reasons, Salesforce restricts the outbound ports: ● 80: This port only accepts HTTP connections. ● 443: This port only accepts HTTPS connections. ● 1024–66535 (inclusive): These ports accept HTTP or HTTPS connections.
- 59. File Upload and Download Security • Helps you control how various file types are handled during upload and download. • Specify what happens when users attempt to download specific file types. • Download (Recommended): The file is always downloaded. • Execute in Browser: The file is displayed and executed automatically when accessed in a browser or through an HTTP request. • Hybrid: Attachment and document records execute in the browser. Salesforce CRM and Chatter files are downloaded.
- 60. File Upload and Download Security
- 61. Egress Controls: CORS • To allow code (such as JavaScript) running in a Web browser to communicate with Salesforce from a specific origin, whitelist the origin. • If a browser that supports CORS makes a request to an origin in the Salesforce CORS whitelist, Salesforce returns the origin in the Access-Control-Allow-Origin HTTP header. • For example, https://*.example.com adds all the subdomains of example.com to the whitelist.