BB2-3486: Mask mbi in logs

[stiwarisemanticbits]

JIRA Ticket:
BB2-3486

What Does This PR Do?

Here we have created sensitive data filter for logging which is going to mask all data across all logs

What Should Reviewers Watch For?

If you're reviewing this PR, please check for these things in particular:

Validation

Make GET request
1EG0TE5MK74 -- This fake mbi
By making below request mbi is masked with ***MBI***

GET http://0.0.0.0:8000//v2/fhir/Patient/identifier=1EG0TE5MK74

In logs we will see

web-1  | 2024-10-15 16:44:15,996 DEBUG [39] hhs_server.apps.fhir.bluebutton.views.generic line:91 resource_type: Patient
web-1  | 2024-10-15 16:44:15,997 DEBUG [39] hhs_server.apps.fhir.bluebutton.views.generic line:92 Interaction: read
web-1  | 2024-10-15 16:44:15,998 DEBUG [39] hhs_server.apps.fhir.bluebutton.views.generic line:93 Request.path: /v2/fhir/Patient/identifier=***MBI***
web-1  | 2024-10-15 16:44:16,096 INFO [39] audit.hhs_oauth_server.request_logging line:81 {
web-1  |   "access_token_hash": "",
web-1  |   "app_id": "",
web-1  |   "app_name": "",
web-1  |   "dev_id": "",
web-1  |   "dev_name": "",
web-1  |   "elapsed": 0.11066508293151855,
web-1  |   "end_time": 1729010656.089619,
web-1  |   "fhir_attribute_count": 1,
web-1  |   "fhir_bundle_type": null,
web-1  |   "fhir_entry_count": null,
web-1  |   "fhir_resource_id": null,
web-1  |   "fhir_resource_type": null,
web-1  |   "fhir_total": null,
web-1  |   "ip_addr": "192.168.65.1",
web-1  |   "location": "",
web-1  |   "path": "/v2/fhir/Patient/identifier=***MBI***",
web-1  |   "req_header_accept_encoding": "gzip, deflate, br",
web-1  |   "req_header_content_type": "text/plain",
web-1  |   "req_header_host": "0.0.0.0:8000",
web-1  |   "req_header_user_agent": "PostmanRuntime/7.42.0",
web-1  |   "request_method": "GET",
web-1  |   "request_scheme": "http",
web-1  |   "request_uuid": "b7213796-8b14-11ef-891a-0242ac120003",
web-1  |   "response_code": 401,
web-1  |   "size": 58,
web-1  |   "start_time": 1729010655.978958,
web-1  |   "type": "request_response_middleware"
web-1  | }
web-1  | 2024-10-15 16:44:16,098 WARNING [39] django.request line:241 Unauthorized: /v2/fhir/Patient/identifier=***MBI***
web-1  | 2024-10-15 16:44:16,102 WARNING [39] django.server line:212 "GET //v2/fhir/Patient/identifier=***MBI*** HTTP/1.1" 401 58

What Security Implications Does This PR Have?

Please indicate if this PR does any of the following:

• Adds any new software dependencies
• Modifies any security controls
• Adds new transmission or storage of data
• Any other changes that could possibly affect security?

• Yes, one or more of the above security implications apply. This PR must not be merged without the ISSO or team
  security engineer's approval.

Any Migrations?

• Yes, there are migrations
  • The migrations should be run PRIOR to the code being deployed
  • The migrations should be run AFTER the code is deployed
  • There is a more complicated migration plan (downtime,
    etc)
• No migrations

[jimmyfagan]

Tests look great, code looks great! Just would want some more local validation before approving, I can do that early next week, or if somebody else can take that over, we should be good to go. Just some validation that this works correctly when the server is run and an MBI-match is passed in. Some steps for that in the description would be great too.

[JFU-NAVA-PBC]

LGTM, some nitch cases:

lower case char in MBI, even though the CMS doc says:
refer to: https://www.cms.gov/medicare/new-medicare-card/understanding-the-mbi-with-format.pdf
"
What kinds of characters are in the MBI? MBIs are numbers and upper-case letters. We use numbers 1-9 and all letters from A to Z, except for S, L, O, I, B, and Z. If you use lowercase letters, our system will convert them to uppercase letters."

considering the mbi literals could come from various sources : human type in, client code sent, etc....

might consider also detect MBI word with lower case...

Did some manual tests - works as expected, e.g.

`>>> result=re.sub(MBI_PATTERN, 'MBI', "1EG4-TE5-MK74 XXX 1EG4TE5MK74", flags=re.VERBOSE)

print(result)
MBI XXX MBI
result=re.sub(MBI_PATTERN, 'MBI', "1EG4-TE5-MK74 XXX 1EG4tE5Mk74", flags=re.VERBOSE)
print(result)
MBI XXX 1EG4tE5Mk74`

[jimmyfagan]

Moving to draft while testing steps get updated and additional code changes are pending.

[jimmyfagan]

Would you mind explaining some of these changes? I'm not too familiar with how some of this is set up, but curious for instance about why the django section needed to be added. I'm doing some reading on this to learn too, but if you can provide some starting context, that might help!

[stiwarisemanticbits]

If you check these logs

web-1  | 2024-10-17 14:59:44,183 WARNING [35] django.request line:241 Unauthorized: /v2/fhir/Patient/identifier=***MBI***
web-1  | 2024-10-17 14:59:44,187 WARNING [35] django.server line:212 "GET //v2/fhir/Patient/identifier=***MBI*** HTTP/1.1"

Here these logs are coming from
django.request and django.server

Adding django to list of loggers will make sure we are capturing all loggers in filter to hide sensitive information.
If we remove this, then some of logs can still log MBI without going via filter. In this case

web-1  | 2024-10-17 14:59:44,187 WARNING [35] django.server line:212 "GET //v2/fhir/Patient/identifier=***MBI*** HTTP/1.1"

MBI will be exposed if we don't have that entry in list of loggers

[jimmyfagan]

Looks mostly good, just two more minor comments but hopefully we can resolve this soon.