Uploaded image for project: 'Atlassian Guard'
  1. Atlassian Guard
  2. ACCESS-1558

IP Allowlist audit log to include incident and IP address of blocked requests

    • 23
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Problem Definition

      The organization audit logs related to IP allowlisting is not sufficient to know when connections are blocked by the allowlist. For security auditing purposes, admins should be able to see data on when blocks occur. 

      We would like logs specifically around documenting user/IP information when a user is denied access because their IP does not fall under any of the ranges set in the Atlassian allowlist.

      Suggested Solution

      Please add all the details for any blocks that happen when connections are denied by the IP allowlist in the organization audit log entry.

      Examples are:

      • User Name of blocked attempt
      • IP address of blocked attempt

      Why this is important

      This is important to track when a blocked attempt is made for security auditing purposes. We would like logs specifically around documenting user/IP information when a user is denied access because their IP does not fall under any of the ranges set in the Atlassian allowlist. Currently, admins have no visibility to these events.

      Workaround

      No workaround is available right now

            [ACCESS-1558] IP Allowlist audit log to include incident and IP address of blocked requests

            Adding an example scenario: when we have to onboard a new client, they usually provide us with one or several IP addresses that (they think) they will be using to access Jira (e.g. their VPN egress IP). However, sometimes they aren't actually using the IPs that they think, because they have some sort of proxy, or CASB (Cloud Access Security Broker) solution, which uses other IPs to access some platforms, such as Jira. When that happens, we have no way of checking whether it's an issue on our part (e.g. the allowlist has been misconfigured or isn't active for some reason) or whether the client is using completely different IPs.

            We've taken to raising Atlassian Support tickets whenever that happens, providing a couple of the Request IDs that appear on the block page. Atlassian Support does have visibility of those events and can provide IPs, from which we can trace back to IP ranges, or network providers, or whatever. It'd be nice if there was an entry in the audit log instead so we could check those blocked request ourselves.

            José Reyes Ruiz added a comment - Adding an example scenario: when we have to onboard a new client, they usually provide us with one or several IP addresses that (they think) they will be using to access Jira (e.g. their VPN egress IP). However, sometimes they aren't actually using the IPs that they think, because they have some sort of proxy, or CASB (Cloud Access Security Broker) solution, which uses other IPs to access some platforms, such as Jira. When that happens, we have no way of checking whether it's an issue on our part (e.g. the allowlist has been misconfigured or isn't active for some reason) or whether the client is using completely different IPs. We've taken to raising Atlassian Support tickets whenever that happens, providing a couple of the Request IDs that appear on the block page. Atlassian Support does have visibility of those events and can provide IPs, from which we can trace back to IP ranges, or network providers, or whatever. It'd be nice if there was an entry in the audit log instead so we could check those blocked request ourselves.

              5cd8def7e384 Kunwardeep Singh
              6b2430609069 Alexis
              Votes:
              17 Vote for this issue
              Watchers:
              18 Start watching this issue

                Created:
                Updated: