Uploaded image for project: 'SAFe Solution'
  1. SAFe Solution
  2. SS-149

Continue AAA roll-out for AA0.5

    XporterXMLWordPrintable

Details

    • Capability
    • Medium
    • PI24
    • None
    • None
    • Observatory, MID, LOW
    • Data Processing, Services, Obs Mgt & Controls
    • Hide

      This provides one layer of our security for our production applications. Together, these features will reduce the risk of deliberate or accidental damage to our software systems and data.

      Show
      This provides one layer of our security for our production applications. Together, these features will reduce the risk of deliberate or accidental damage to our software systems and data.
    • Hide
      • For each application we must define and document, to facilitate review by our architect and our security team:
      • a set of user groups, which are mapped on to the application's capabilities, which allow restriction of access based on roles (e.g. restrict roles to read-only access)
      • a set of group managers (must be SKAO staff or associates) - these people will need to manage group membership. We favour smaller groups with well-defined membership. Groups can contain other groups in a hierarchy.
      • timeouts - when do we lock a user's access and force re-authentication (with or without forcing an MFA token refresh)? This can be different for different applications - for applications like Binderhub with the most access, we expect shorter timeouts.
      • activity logs: what user is running what command. Can be more minimal for lower-risk apps, and must be more extensive for higher risk apps.
      • based on activity logs or other indicators, when do we freeze accounts, or raise an alarm/alert?
      • a set of tests to show that you can gain appropriate access if in the correct group, and that access is denied if you are not in the correct group, ideally in an XRAY test plan showing successful test executions. See example mapping on Miro
      • a set of tests to show we are validating tokens appropriately
      Show
      For each application we must define and document, to facilitate review by our architect and our security team: a set of user groups, which are mapped on to the application's capabilities, which allow restriction of access based on roles (e.g. restrict roles to read-only access) a set of group managers (must be SKAO staff or associates) - these people will need to manage group membership. We favour smaller groups with well-defined membership. Groups can contain other groups in a hierarchy. timeouts - when do we lock a user's access and force re-authentication (with or without forcing an MFA token refresh)? This can be different for different applications - for applications like Binderhub with the most access, we expect shorter timeouts. activity logs: what user is running what command. Can be more minimal for lower-risk apps, and must be more extensive for higher risk apps. based on activity logs or other indicators, when do we freeze accounts, or raise an alarm/alert? a set of tests to show that you can gain appropriate access if in the correct group, and that access is denied if you are not in the correct group, ideally in an XRAY test plan showing successful test executions. See example mapping on Miro a set of tests to show we are validating tokens appropriately
    • PI24 - UNCOVERED

    Description

      The work that was set to Should or Could have priorities for PI23 still needs to be completed, and is of a higher priority as AA0.5 Low will be in use by AIV by the end of PI23.
      ADR-34 will be decided. See https://miro.com/app/board/uXjVKY4iwmw=/?moveToWidget=3458764584901670013&cot=14 for the state as at the end of PI23 planning, and follow ADR-34 for updates.

      Capability definition for PI24 to reside here in Miro: https://miro.com/app/board/uXjVKgORG8Q=/?moveToWidget=3458764599644094397&cot=14

       

      Attachments

        Issue Links

          Features

          Structure

            Activity

              People

                v.allan Allan, Verity
                v.allan Allan, Verity
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Capability Progress

                  Feature Point Burn-up: (0%)

                  Capability Estimate: 0

                  CountFeature Points
                  Todo613
                  In Progress   414
                  Done00
                  Total1020

                  Dates

                    Created:
                    Updated:

                    Structure Helper Panel