03. Data Security

03. Data Security

1. make sure all users can easily get the data they need.

2. control access to your whole org, a specific object, a specific field, or even an individual record

3. Audit System Use

   • provides important information for diagnosing potential security issues or dealing with real ones.
   • Record Modification Fields
     • All objects include fields to store the name of the user who created the record and who last modified the record
       • provides some basic auditing information
   • Login History
     • review a list of successful and failed login attempts for the past six months
   • Field History Tracking
     • turn on auditing to automatically track changes in the values of individual fields
     • isn't enabled
       • data is retained for up to 18 months, and up to 24 months via the API
     • is enabled
       • field history data is retained until manually deleted
     • select certain fields to track
       • up to 20 fields
       • modifying fields adds an entry to the history related list, including the date, time, nature of the change, and who made the change
   • Setup Audit Trail
     • logs when modifications are made to your organization’s configuration
       • ex: tracks fields history
     • tracks the recent setup changes that you and other admins make to your SF org.
       • Audit history is especially useful in orgs with multiple admins
       • 6 moths
   • Health Check
     • identify and fix potential vulnerabilities in your security settings
   • Profile and permission Set helper App
     • contains tools to simplify your permissions processes
       • profile to permission set converter
       • permission analyzer

4. Control Access to the Org

   • protecting your data at the broadest level
   • Manage Users
     • SF user is identified by a username, a password, and a single profile
       • profile determines what tasks users can perform, what data they see, and what they can do with the data
     • You can't delete a user, but you can deactivate an account so a user can’t log in or freeze him.
   • Set Password Policy
     • first line of defence
     • Password policies
       • such as specifying an amount of time before all users’ passwords expire and the level of complexity required for passwords
         • never share passwords
         • make passwords harder to crack
         • longer passwords are better
         • require unique passwords
         • change passwords often
     • User password expiration
       • Expire the passwords for all the users in your org, except for users with “Password Never Expires” permission.
     • User password resets
       • Reset the password for specified users.
     • Login attempts and lockout periods
       • unlock the person’s access
   • Trusted IP Ranges
     • first time you log in to SF, the IP address is cached in your browser
     • bypass the step for asked to verify your identity, typically by entering a verification code
     • profile IP ranges
       • users with selected profile who are outside the trusted range can't log in
       • path: setup / profiles / login IP ranges
   • Login Access by Time
     • specify the hours when users can log in
     • path: setup / profiles / profile to change / login hours
     • If users are logged in when their login hours end, they can continue to view their current page, but they can’t take any further action.
   • Multi-Factor Authentication (MFA)
     • effective way to increase protection for user accounts against common like phishing attacks, credential stuffing, and account takeovers
     • set policies that require a second level of athentication
       • SF Authenticator App
   • My Domain
     • customer-specific name to include in your SF org URLs
     • are more secure
   • Single sign-on (SSO)
     • require My domain
     • enables users to access multiple app with one login and one set of credentials
     • one system to trust another to authenticate users
       • eliminating the need users to log in to each system separately
   • SF authenticate before allowing a user to log in the user interface whether the org has trusted IP address and the user's profile has login hour restrictions

5. Activities

   • are records of the interactions your org has with records such as your accounts, contacts and opportunities
   • they can be either
     • tasks
       • user-created (to do or call log) and created by system (email)
       • marked as completed by user when done
     • events
       • user-scheduled interactions, whit a start and end date, which appear on calender
       • automatically marked as completed when start data is reached
   • activity timeline is supported for accounts, cases, claims, contacts, contracts, insurance policies, leads, opportunities, and activity-enabled custom objects