Linux cho DE 5 — Quyền, người dùng & truyền dữ liệu (SSH)
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, scp và rsync. 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ân và ký 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:
| Octal | rwx | Ý nghĩa |
|---|---|---|
755 | rwxr-xr-x | Thư mục/script: owner toàn quyền, còn lại đọc+chạy |
644 | rw-r--r-- | File thường công khai đọc: owner ghi, còn lại chỉ đọc |
640 | rw-r----- | File dữ liệu nội bộ: owner ghi, group đọc, other cấm |
600 | rw------- | Bí mật: chỉ owner đọc-ghi (dùng cho SSH key, .env) |
700 | rwx------ | 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/passwdlà 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 groupdedata. - 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 /tmpcho radrwxrwxrwt.
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ữxnghĩ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 userdeuserrestart service Airflow chứ không chorm -rfbấ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ớichmod 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ượng | Quyền | Lý do |
|---|---|---|
~/.ssh | 700 | Chỉ owner vào được |
~/.ssh/id_ed25519 (private) | 600 | Không ai ngoài owner đọc được khoá riêng |
~/.ssh/id_ed25519.pub | 644 | Công khai, đọc được |
~/.ssh/authorized_keys | 600 | Ngă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 |
|---|---|
-a | archive: giữ nguyên quyền, owner/group, timestamp, đệ quy, symlink |
-v | verbose: in danh sách file đang truyền |
-z | nén dữ liệu trên đường truyền (tốt cho mạng chậm) |
--progress | hiện tiến độ từng file (tốc độ, % hoàn thành) |
--partial | giữ lại phần đã truyền dở → resume khi chạy lại |
--delete | xoá ở đích những file không còn ở nguồn (mirror thật sự) |
--dry-run | chạy thử, chỉ in ra sẽ làm gì mà không đổi gì |
--exclude | bỏ 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
640với group hạn chế,umask 027.find /data -perm -o=r -type fgiúp truy quét file nào đang bị other đọc. - Khoá riêng luôn
600và 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
PasswordAuthenticationtrongsshd_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:
- Trên máy jump của DE:
ssh-keygen -t ed25519 -C "de-batch@ncb", rồissh-copy-id [email protected]và tương tự choanalytics. Đặt~/.ssh/id_ed25519về600,~/.sshvề700. - Khai báo hai host
corevàanalyticstrong~/.ssh/configđể lệnh gọn. - Trên server core, thư mục export dùng setgid + group hạn chế:
sudo chgrp dedata /export && sudo chmod 2750 /export,umask 027trong profile của service account → mọi file sinh ra là640, groupdedata, 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. chmodsố (755/644/640/600) hoặc ký hiệu (u+x,g-w,o=);chown user:group;-Rcho đệ quy,Xviết hoa chỉ thêm x cho thư mục.umask 027(hoặc077) 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 +
sudogiớ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êng600,~/.ssh700, khai báo host trong~/.ssh/config. scpcho copy một lần;rsync -avz --progresscho đồ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êng600, 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.
Container vs máy ảo, image/layer, Dockerfile, volume, network, Docker Compose và best practices.
Vì sao cần orchestration; Pod, Deployment, Service, Ingress; scaling, self-healing và cấu hình.
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á.