Sign in Subscribe

Mantra If I cannot secure the data, I have no business working with it.

TL;DR: With great powers comes great responsibility. I got a big scare when I learned that I had unknowingly exposed my Google Service Account key to anyone with access to my machine. This is the story of how I discovered this massive potential security breach, and what I did to close it.

¿Qué pasó?

I did not know how to safeguard secret files🤫🗃️. I knew I couldn't allow my capabilities to access data outpace my ability to secure it. I needed to learn how to lock down the Google service account key that grants access to all of our team's digital resources.

Step One: .gitignore my .secrets folder: ✅

Step Two: Add key file path to my environmental variables (USER) and only reference the variable in my code: ✅

Step Three: Lock down permissions to my .secrets folder: 😮

When I ran icacls $p to probe permissions, I saw that my service account key was available to anyone who could access my computer - even guests!

BUILTIN\Administrators:(I)(F) BUILTIN\Administrators:(I)(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(I)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F) NT AUTHORITY\Authenticated Users:(I)(M) NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M) BUILTIN\Users:(I)(RX) BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

Legend: (I)=inherited, (OI)=object inherit to files, (CI)=container inherit to subfolders, (IO)=inherit-only, (F)=full control, (M)=modify, (RX)=read/execute.

What I did (two commands)

1) Remove inheritance, 2) grant myself Modify and (optionally) keep SYSTEM read-only. Use a variable for the username to avoid quoting issues.

# Set folder path and expand your username $p = "D:\path\to\folder" $user = $env:USERNAME # 1) Break inheritance (stop pulling broad ACLs from parent) icacls $p /inheritance:r # 2) Set explicit, tight ACLs # - You: Modify (applies to files and subfolders) # - SYSTEM: Read () icacls $p /grant:r "$user:(OI)(CI)(M)" "SYSTEM:(OI)(CI)(R)"

Note: icacls manages Windows file permissions (ACLs). And, yes, it is pronounced "I Cackles."

Verify the result

After running these, the permissions looked clean and precise.

icacls $p # Expected: # COMPUTERNAME\YourUser:(OI)(CI)(M) # NT AUTHORITY\SYSTEM:(OI)(CI)(R)

Key Hygiene Principles

  • Begin every project with an inventory of potential attack vectors and a clear security plan. If I cannot secure the data, I have no business working with it.
  • Ensure all secret files are .gitignored.
  • Never commit a service account JSON.
  • Never log a key or paste it into code, README, comments, or issues.
  • Set explicit permissions for files with sensitive information at the level of least privilege.
  • Apply the Least Privilege Principle for service account shares.
  • Add .secrets\ to environment variables to avoid hard-coding full paths and to improve portability.
  • Rotate keys regularly and after any potential breach.
  • Use only official, up-to-date client libraries.
  • Call all APIs over HTTPS and trusted networks.
  • Exclude .secrets\ from back-ups.
  • Document how keys are used and protected.

Incident Response

If a secret key is ever exposed, act immediately:

  1. Rotate immediately: Google Cloud Console → IAM & Admin → Service Accounts → your SA → Keys → Add key (JSON) → download → Delete old key.
  2. Purge history: Remove the file, commit, then rewrite history (BFG or git filter-repo) to strip the old JSON from all commits.
  3. Audit & tighten: Review IAM roles for the service account; narrow scope where possible.
  4. Document: Add a short incident note in your repo (date, action taken).

Takeaway

Data security is a complex topic. It has to be job number one for any data professional in today's world. If I cannot secure the data, I have no business working with it.

tags: #infosec, #applied-learning, #data-science, #IAM, #Google

My first foray into InfoSec: Locking down .secrets\