Linux cho DE 5 — Quyền, người dùng & truyền dữ liệu (SSH)

13 thg 7, 2026 2 lượt xem
#security
#devops
#linux
#ssh
#permissions
#rsync

Vì sao quyền hạn là chuyện sống còn với DE ngân hàng

Trong ngân hàng, một file dữ liệu không chỉ là byte trên đĩa — nó là danh sách khách hàng, số dư tài khoản, lịch sử giao dịch. Một file export core banking để nhầm quyền world-readable trên server dùng chung có thể trở thành sự cố lộ dữ liệu cá nhân, vi phạm quy định bảo vệ dữ liệu và chính sách nội bộ. Data engineer là người trực tiếp tạo, di chuyển và đồng bộ những file này giữa các máy, nên hiểu mô hình quyền Unix không phải kiến thức "cho vui" mà là kỹ năng phòng vệ hằng ngày.

Bài này chia hai nửa. Nửa đầu: ai được làm gì với file nào — mô hình quyền, chmod/chown/umask, quyền đặc biệt, user/group và sudo. Nửa sau: làm sao đi vào server và mang dữ liệu qua lại an toàn — SSH key auth, scprsync. Bài nối tiếp Linux 2 — File & điều hướng và bổ trợ cho Bảo mật & SRE.


Mô hình quyền Unix: ai, làm gì

Mỗi file/thư mục trên Linux có một chủ sở hữu (owner/user), thuộc một nhóm (group), và phần còn lại của thế giới là other. Với mỗi trong ba đối tượng này, hệ thống lưu ba bit quyền:

  • r (read = 4): đọc nội dung file; với thư mục là liệt kê tên các mục bên trong.
  • w (write = 2): sửa/ghi đè file; với thư mục là tạo/xoá/đổi tên mục bên trong.
  • x (execute = 1): thực thi file (script/binary); với thư mục là đi vào (cd) và truy cập mục bên trong theo tên.

Điểm hay nhầm: với thư mục, x quan trọng hơn tưởng tượng. Không có x trên thư mục thì dù có r bạn cũng không cd vào được, và không mở được file bên trong dù biết đường dẫn.

Đọc output của ls -l

drwxr-xr-x  2 deuser  dedata  4096 Jun 30 09:12 exports
-rw-r-----  1 deuser  dedata  2048 Jun 30 09:15 customers_2026.csv

Chuỗi 10 ký tự đầu tiên là chìa khoá:

Với drwxr-xr-x: đây là thư mục (d); owner có đủ rwx; group có r-x (đọc + vào, không ghi); other cũng r-x. Với file -rw-r-----: file thường, owner đọc-ghi, group chỉ đọc, other không có quyền gì — đây chính là mức nên đặt cho file chứa dữ liệu khách hàng. Hai cột deuser dedata là owner và group; số 1/2 sau quyền là số hard link.


chmod: đổi quyền

chmod (change mode) có hai cú pháp: số bát phânký hiệu.

Cú pháp số (octal)

Cộng các giá trị r=4, w=2, x=1 cho từng nhóm user/group/other:

OctalrwxÝ nghĩa
755rwxr-xr-xThư mục/script: owner toàn quyền, còn lại đọc+chạy
644rw-r--r--File thường công khai đọc: owner ghi, còn lại chỉ đọc
640rw-r-----File dữ liệu nội bộ: owner ghi, group đọc, other cấm
600rw-------Bí mật: chỉ owner đọc-ghi (dùng cho SSH key, .env)
700rwx------Thư mục riêng tư: chỉ owner vào được
chmod 640 customers_2026.csv     # rw-r-----
chmod 755 deploy.sh              # rwxr-xr-x

Cú pháp ký hiệu

Dạng [ugoa][+-=][rwx] — tiện khi chỉ muốn bật/tắt một bit mà không cần tính lại toàn bộ:

chmod u+x deploy.sh       # thêm execute cho owner
chmod g-w report.csv      # bỏ write của group
chmod o= secrets.env      # gỡ sạch quyền của other (o=)
chmod -R g+rX exports/    # đệ quy: group đọc file + vào thư mục

X viết hoa là mẹo rất hữu ích: chỉ thêm x cho thư mục hoặc file vốn đã có x, không vô tình biến mọi file dữ liệu thành "thực thi được". -R chạy đệ quy toàn cây thư mục.


chown / chgrp: đổi chủ sở hữu

chown deuser customers.csv           # đổi owner
chown deuser:dedata customers.csv    # đổi cả owner và group
chgrp dedata customers.csv           # chỉ đổi group
chown -R airflow:airflow /data/staging/   # đệ quy cả cây

Đổi owner thường cần sudo (chỉ root mới có quyền "cho đi" file của người khác). Đây là thao tác kinh điển khi bàn giao file: pipeline chạy bằng user airflow ghi ra /data/staging, sau đó bạn cần chown sang group dedata để đội phân tích đọc được — mà không cần cấp quyền cho toàn bộ server.


umask: quyền mặc định khi tạo file

Khi bạn tạo file mới, quyền của nó không phải 777 mà bị "trừ" đi theo umask. Mặc định file mới là 666 (rw cho tất cả), thư mục là 777; umask là mặt nạ loại bỏ bit:

  • umask 022 (phổ biến): file → 644, thư mục → 755. Other vẫn đọc được.
  • umask 027: file → 640, thư mục → 750. Other không đọc được — nên đặt trên server dữ liệu.
  • umask 077: file → 600, thư mục → 700. Chỉ owner. Chặt nhất.
umask            # xem mask hiện tại
umask 027        # đặt cho phiên hiện tại

Với server chứa dữ liệu khách hàng, đặt umask 027 (hoặc 077) trong ~/.bashrc của user chạy job giúp mọi file sinh ra tự động không world-readable, thay vì phải nhớ chmod từng file — một cơ chế phòng vệ chủ động.


Quyền đặc biệt: setuid, setgid, sticky bit

Ngoài rwx còn ba bit đặc biệt, xuất hiện ở vị trí x:

  • setuid (4xxx, chữ s ở owner): chạy binary với quyền của owner file thay vì người gọi. Ví dụ /usr/bin/passwd là setuid-root để user thường đổi được mật khẩu. Rất nhạy cảm — đừng bao giờ đặt setuid cho script tự viết.
  • setgid (2xxx, chữ s ở group): trên thư mục, file mới tạo bên trong sẽ kế thừa group của thư mục thay vì group của người tạo. Cực hữu ích cho thư mục dùng chung: chmod 2775 /data/shared && chgrp dedata /data/shared đảm bảo mọi file đội tạo ra đều thuộc group dedata.
  • sticky bit (1xxx, chữ t ở other): trên thư mục ghi-chung như /tmp, chỉ owner của file mới xoá được file của mình, người khác không xoá xen được. ls -ld /tmp cho ra drwxrwxrwt.
chmod 2775 /data/shared    # setgid + rwxrwxr-x
chmod 1777 /scratch        # sticky, giống /tmp

User & group: hệ thống nhận diện thế nào

Mỗi user có một UID, mỗi group một GID. Ánh xạ tên ↔ số nằm ở các file text:

  • /etc/passwd: một dòng/user — deuser:x:1001:1001:DE User:/home/deuser:/bin/bash (tên : x : UID : GID chính : mô tả : home : shell). Chữ x nghĩa là mật khẩu (hash) nằm ở /etc/shadow, file chỉ root đọc được.
  • /etc/group: định nghĩa group và thành viên phụ.
id              # UID, GID chính và mọi group phụ của bạn
id deuser       # thông tin của user khác
groups          # liệt kê các group đang thuộc
whoami          # tên user hiện tại
getent passwd deuser   # tra passwd (cả khi dùng LDAP/AD)

Câu hỏi thường gặp: "Tôi đã thêm mình vào group dedata nhưng vẫn không đọc được file?" — thành viên group mới chỉ có hiệu lực ở phiên đăng nhập mới. Đăng xuất/đăng nhập lại, hoặc chạy newgrp dedata.


sudo & nguyên tắc least privilege

sudo cho phép chạy một lệnh với quyền cao hơn (mặc định là root) mà không cần đăng nhập trực tiếp bằng root. Nguyên tắc least privilege (đặc quyền tối thiểu): mỗi người/tiến trình chỉ nên có đúng quyền cần thiết, không hơn.

Trên server dữ liệu ngân hàng, điều này nghĩa là:

  • Không dùng chung tài khoản root. Mỗi người một user riêng, cấp quyền qua sudo để mọi thao tác đều truy vết được ai làm gì (audit log trong /var/log/auth.log).
  • Cấp sudo theo lệnh cụ thể, không cấp "sudo tất cả". File /etc/sudoers.d/ cho phép giới hạn: ví dụ chỉ cho phép user deuser restart service Airflow chứ không cho rm -rf bất kỳ đâu.
  • Job pipeline chạy bằng service account riêng (như airflow), không chạy bằng root. Nếu job bị chiếm quyền, thiệt hại giới hạn trong phạm vi user đó.
  • Dữ liệu khách hàng đặt group riêng (dedata) với chmod 640/umask 027, chỉ thành viên được thêm vào group mới đọc được.

Đây là tấm nền của mọi kiểm soát truy cập; xem thêm góc pháp lý ở Quyền riêng tư & tuân thủ.


SSH: đi vào server an toàn

SSH (Secure Shell) là cách chuẩn để đăng nhập từ xa vào server Linux qua kênh mã hoá. Có hai kiểu xác thực: bằng mật khẩu (yếu, dễ bị brute-force) và bằng cặp khoá công khai/riêng (public/private key) — cách nên dùng.

Nguyên lý: bạn tạo một cặp khoá. Khoá riêng (private key) giữ tuyệt mật trên máy bạn; khoá công khai (public key) copy lên server. Khi kết nối, server thách thức bằng khoá công khai, chỉ ai giữ khoá riêng tương ứng mới trả lời đúng. Khoá riêng không bao giờ rời máy bạn.

Tạo và cài khoá

ssh-keygen -t ed25519 -C "deuser@ncb"   # tạo cặp khoá ed25519 (khuyến nghị)
# sinh ~/.ssh/id_ed25519 (riêng) và ~/.ssh/id_ed25519.pub (công khai)

ssh-copy-id deuser@data-server          # tự thêm .pub vào authorized_keys của server

Trên server, khoá công khai nằm ở ~/.ssh/authorized_keys (mỗi khoá một dòng). SSH rất khó tính về quyền: nếu quyền quá rộng, nó từ chối dùng khoá để tránh rủi ro. Quy tắc bắt buộc:

Đối tượngQuyềnLý do
~/.ssh700Chỉ owner vào được
~/.ssh/id_ed25519 (private)600Không ai ngoài owner đọc được khoá riêng
~/.ssh/id_ed25519.pub644Công khai, đọc được
~/.ssh/authorized_keys600Ngăn người khác thêm khoá lạ

Nếu SSH cứ đòi mật khẩu dù đã cài khoá, thủ phạm gần như luôn là khoá riêng quá "mở" (chmod 600 ~/.ssh/id_ed25519).

File ~/.ssh/config

Thay vì gõ đường dẫn khoá và user dài dòng mỗi lần, khai báo host một lần:

Host data
    HostName 10.20.30.40
    User deuser
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Sau đó chỉ cần ssh data. File config này cũng nên chmod 600.


Truyền dữ liệu: scp và rsync

Đây là phần "cơm áo" của DE: mang dataset qua lại giữa laptop, server staging và server production. Cả hai chạy trên nền SSH nên hưởng đúng bảo mật đã cấu hình ở trên.

scp — copy đơn giản

scp (secure copy) copy file/thư mục một lần, giống cp nhưng qua mạng:

scp report.csv deuser@data:/data/incoming/       # đẩy lên server
scp deuser@data:/data/exports/daily.csv ./        # kéo về
scp -r exports/ deuser@data:/data/backup/         # -r cho cả thư mục

scp đơn giản nhưng không có resume, không so sánh khác biệt — mỗi lần copy lại từ đầu. Với file lớn hoặc đồng bộ lặp lại, dùng rsync.

rsync — đồng bộ thông minh, incremental

rsync chỉ truyền phần khác biệt giữa nguồn và đích, nên đồng bộ lần hai cực nhanh. Đây là công cụ chủ lực để đồng bộ dataset lớn và incremental (chỉ file mới/đổi).

rsync -avz --progress /data/exports/ deuser@data:/backup/exports/

Bóc tách các cờ thường dùng:

CờÝ nghĩa
-aarchive: giữ nguyên quyền, owner/group, timestamp, đệ quy, symlink
-vverbose: in danh sách file đang truyền
-znén dữ liệu trên đường truyền (tốt cho mạng chậm)
--progresshiện tiến độ từng file (tốc độ, % hoàn thành)
--partialgiữ lại phần đã truyền dở → resume khi chạy lại
--deletexoá ở đích những file không còn ở nguồn (mirror thật sự)
--dry-runchạy thử, chỉ in ra sẽ làm gì mà không đổi gì
--excludebỏ qua file/thư mục theo pattern

Điểm cần nhớ về dấu / cuối nguồn: rsync -a src/ dst/ copy nội dung bên trong src vào dst; còn rsync -a src dst/ tạo dst/src. Sai chỗ này là hay nhân đôi thư mục.

# Đồng bộ incremental hằng ngày, có resume, bỏ qua file tạm, chạy thử trước
rsync -avz --partial --progress \
      --exclude '*.tmp' --exclude '_SUCCESS' \
      --dry-run \
      /data/warehouse/daily/ deuser@backup:/archive/daily/

Bỏ --dry-run khi đã ưng kết quả. Kết hợp rsync với cron (xem Linux 7 — Lập lịch & systemd) là mẫu backup/đồng bộ kinh điển.


Lưu ý bảo mật cho DE ngân hàng

  • Không để dữ liệu nhạy cảm world-readable. File chứa PII/giao dịch nên 640 với group hạn chế, umask 027. find /data -perm -o=r -type f giúp truy quét file nào đang bị other đọc.
  • Khoá riêng luôn 600 và không bao giờ commit vào git, không copy lên server dùng chung, không gửi qua chat.
  • Không dùng mật khẩu SSH trên server production; tắt PasswordAuthentication trong sshd_config, chỉ dùng key.
  • Least privilege: mỗi user/service account đúng quyền cần. Không chạy job bằng root.
  • rsync giữ nguyên quyền với -a — tốt, nhưng nghĩa là nếu nguồn có file world-readable, đích cũng vậy. Kiểm quyền cả hai đầu.

Use case thực tế

Bối cảnh: Đội DE cần đưa file export core banking customers_full.csv (khoảng 4,2 GB, ~3,1 triệu dòng) từ server core (10.20.30.40) về server phân tích (analytics) mỗi đêm, an toàn và incremental, chỉ cho group dedata đọc.

Thiết lập một lần:

  1. Trên máy jump của DE: ssh-keygen -t ed25519 -C "de-batch@ncb", rồi ssh-copy-id [email protected] và tương tự cho analytics. Đặt ~/.ssh/id_ed25519 về 600, ~/.ssh về 700.
  2. Khai báo hai host coreanalytics trong ~/.ssh/config để lệnh gọn.
  3. Trên server core, thư mục export dùng setgid + group hạn chế: sudo chgrp dedata /export && sudo chmod 2750 /export, umask 027 trong profile của service account → mọi file sinh ra là 640, group dedata, other cấm.

Job hằng đêm (đặt qua cron 01:00):

rsync -avz --partial --progress \
      --exclude '*.tmp' \
      core:/export/customers_full.csv \
      /data/incoming/

Kết quả & con số minh hoạ: Đêm đầu truyền toàn bộ 4,2 GB (với -z nén còn ~1,3 GB trên đường truyền). Các đêm sau, khi file chỉ thay đổi ~2% số dòng, rsync truyền delta nên thời gian giảm từ ~9 phút xuống dưới 40 giây. Nếu mạng đứt giữa chừng, --partial cho phép chạy lại tiếp tục từ chỗ dở. File về đích giữ nguyên quyền 640/group dedata (nhờ -a), nên đội phân tích trong group đọc được còn user ngoài group không đụng vào được — đúng yêu cầu bảo vệ dữ liệu khách hàng.

Kiểm chứng sau job:

ssh analytics 'ls -l /data/incoming/customers_full.csv'
# -rw-r----- 1 deuser dedata 4508123456 ... customers_full.csv
ssh analytics 'find /data/incoming -perm -o=r -type f'   # phải rỗng

Ghi nhớ

  • Quyền Unix = ba đối tượng (user/group/other) × ba bit (r=4, w=2, x=1); trên thư mục x = quyền đi vào, r = quyền liệt kê.
  • Đọc ls -l: 10 ký tự đầu = loại + rwx cho owner/group/other. -rw-r----- = file dữ liệu nội bộ chuẩn.
  • chmod số (755/644/640/600) hoặc ký hiệu (u+x, g-w, o=); chown user:group; -R cho đệ quy, X viết hoa chỉ thêm x cho thư mục.
  • umask 027 (hoặc 077) trên server dữ liệu để file mới tự động không world-readable.
  • Quyền đặc biệt: setgid trên thư mục giúp file kế thừa group (dùng cho thư mục chung); sticky bit bảo vệ /tmp; setuid rất nhạy cảm, tránh dùng cho script tự viết.
  • User/group tra ở /etc/passwd, /etc/group; id, groups, whoami. Thêm group phải đăng nhập lại mới có hiệu lực.
  • Least privilege: user riêng + sudo giới hạn theo lệnh, service account riêng cho pipeline, không dùng root.
  • SSH key auth an toàn hơn mật khẩu; ssh-keygen -t ed25519, ssh-copy-id, khoá riêng 600, ~/.ssh 700, khai báo host trong ~/.ssh/config.
  • scp cho copy một lần; rsync -avz --progress cho đồng bộ incremental — chỉ truyền delta, --partial để resume, chú ý dấu / cuối nguồn.
  • Dữ liệu khách hàng: 640 + group hạn chế, khoá riêng 600, tắt password auth trên production, kiểm quyền hai đầu khi rsync.

Bài viết liên quan

Continuous Integration/Delivery/Deployment, cấu trúc pipeline, ví dụ GitHub Actions và chiến lược release.

13 thg 7, 2026 4

Container vs máy ảo, image/layer, Dockerfile, volume, network, Docker Compose và best practices.

13 thg 7, 2026 3

Vì sao cần orchestration; Pod, Deployment, Service, Ingress; scaling, self-healing và cấu hình.

13 thg 7, 2026 3

Bản chất DevOps: phá bỏ rào cản Dev–Ops, vòng lặp vô tận, CALMS, và vì sao tự động hoá.

13 thg 7, 2026 3