PII Prevention | Implement Sidekiq Filtering

[davidbecker6081]

Summary

In light of numerous PII exposures, it would be in our interest to develop a way to mitigate those and catch them before they happen (and we have to report an incident).

For examples:

• Bug | Address BGS ORA-20099 PII leak for 686c va.gov-team#118858
• Bug | BGS::SubmitForm686cV2Job PII Leak va.gov-team#118865

An initial thought is to build a custom filtering log method for our BGS and Lighthouse Jobs (anything async). Monitor logging is already covered by Tai's code that scrubs particular types of data here

In the section "Log Filtering", https://www.rubydoc.info/gems/sidekiq_parameters_logging, you'll see an example of implementing a custom logger_filter. Perhaps we can apply that alongside ParameterFilterHelper.filter_params(params) (https://depo-platform-documentation.scrollhelp.site/developer-docs/personal-identifiable-information-pii-guidelines) to make sure our async jobs are, by default, not logging PII data.

What would this allow for?

We could have less concern with needing to pass in sensitive PII data for async jobs to run, especially when we can be more explicit in the arguments we define, rather than passing in an encrypted data object as seen with the submit686cV2job#perform

class Worker
  include Sidekiq::Worker
  include Sidekiq::Parameters::Logger

  logger_filter do |param1, param2|
    all_params = [param1, param2]
    filtered_params = ParameterFilterHelper.filter_params(all_params)
    filtered_params # only print out the filtered list
  end

  def perform(param1, param2)
    # do something
  end
end

Tasks

• Implement a re-usable sidekiq parameter filtering method/concern
• Test that implementation filters sensitive params in DD

Acceptance Criteria

• PII data is being filtered even when passed in perform methods for sidekiq jobs

Engineering Notes

• The first place to implement this would be where the icn leaks occurred from the issue stated above (within the submitForm686cV2Job#perform