Hiện tại thì Locker chưa công bố giá chính thức và vẫn để user sử dụng miễn phí trong thời gian đầu bạn ạ, mk cũng ko rõ lắm. Để chắc chắn hơn bn thử contact với customer support xem 😅
Theo mk, ko chỉ webhook URLs mà cả những thông tin nhỏ như credentials cho dịch vụ nội bộ cũng cần được bảo vệ. Nhưng mk cũng chuea bt làm sao để quản lý tất cả mà không quá phức tạp? Ae nào có kinh nghiệm chia sẻ thêm đi
Bn có thể thử mã hóa webhook URLs trc khi lưu hoặc sd các token xác thực cho từng webhook. nếu nền tảng hỗ trợ, thiết lập IP whitelist để giới hạn nguồn gửi yêu cầu tới webhook của bn
Mã hóa trc khi lưu database là điều nên làm, vì cũng yên tâm hơn nếu database bị xâm phạm. Nhg nếu muốn đơn giản hóa, bn thử ctham khảo các công cụ hỗ trợ, mk đang dùng secrets manager của bên Locker 1 thời gian thì thấy cũng ok, hoặc một dịch vụ tương tự cũng đc vì nó đã tích hợp mã hóa sẵn
Mk nghĩ vấn đề nằm ở độ nhạy cảm của secrets. Nếu đó là API key hoặc token quan trọng, tốt nhất vẫn nên mã hóa trước khi lưu. Nhưng với các secrets ít quan trọng hơn, có thể chỉ cần kiểm soát quyền truy cập là đủ. Kbt mn thg phân loại secrets theo cách nào để quyết định mức độ bảo mật?
công nhận là xử lý đc bài toán routing này khá là chuối, nhưng chúng ta nên chọn giải pháp sao cho phù hợp với business của từng người mình nghĩ là cũng oke rồi, ko cần cover hết mọi trường hợp ko cần thiết.
Với cả nếu xử lý được routing thì sẽ dễ hơn nhiều để ta đưa các app đang là standalone vào kiến trúc MFE:
ví dụ như đang có vài team maintain project của họ riêng, làm sao ta họ có thể đưa app của họ vào MFE dễ nhất, thường là các app đó sẽ có routing các thứ
ví dụ nếu ta muốn lấy một app open source về để phục vụ cho business của cty, liệu có dễ dàng??
Thực tế khi mình làm MFE thì mình lại thấy App view cũng phổ biến ko kém Widget view, rất nhiều team họ có app sẵn và thường họ sẽ chỉ ok dùng MFE nếu kiến trúc support routing cho họ
Cá nhân mình thấy việc xử lý routing trong các micro-frontend là rất khó khả thi vì với mỗi micro sẽ áp dụng các thư viện khác nhau rất dễ chồng chéo và ko kiểm soát đc. Với routing hoặc các thứ khác liên quan tới trình duyệt mình sẽ luôn đặt ở root app. Các front-end chỉ cung cấp phần UI và 1 số thứ khác liên quan.
THẢO LUẬN
Hiện tại thì Locker chưa công bố giá chính thức và vẫn để user sử dụng miễn phí trong thời gian đầu bạn ạ, mk cũng ko rõ lắm. Để chắc chắn hơn bn thử contact với customer support xem 😅
Theo mk, ko chỉ webhook URLs mà cả những thông tin nhỏ như credentials cho dịch vụ nội bộ cũng cần được bảo vệ. Nhưng mk cũng chuea bt làm sao để quản lý tất cả mà không quá phức tạp? Ae nào có kinh nghiệm chia sẻ thêm đi
Bn có thể thử mã hóa webhook URLs trc khi lưu hoặc sd các token xác thực cho từng webhook. nếu nền tảng hỗ trợ, thiết lập IP whitelist để giới hạn nguồn gửi yêu cầu tới webhook của bn
Mã hóa trc khi lưu database là điều nên làm, vì cũng yên tâm hơn nếu database bị xâm phạm. Nhg nếu muốn đơn giản hóa, bn thử ctham khảo các công cụ hỗ trợ, mk đang dùng secrets manager của bên Locker 1 thời gian thì thấy cũng ok, hoặc một dịch vụ tương tự cũng đc vì nó đã tích hợp mã hóa sẵn
@Phannhatnam Team mk đang dùng trình quản lý secret của Locker, bạn gõ locker tìm website là có in4 đầy đủ tham khảo xem sao
Mk nghĩ vấn đề nằm ở độ nhạy cảm của secrets. Nếu đó là API key hoặc token quan trọng, tốt nhất vẫn nên mã hóa trước khi lưu. Nhưng với các secrets ít quan trọng hơn, có thể chỉ cần kiểm soát quyền truy cập là đủ. Kbt mn thg phân loại secrets theo cách nào để quyết định mức độ bảo mật?
giá của bên này tn v bạn?
Cho mk hỏi là bên Locker này có cung cấp chức năng giám sát hđ để theo dõi địa điểm và thời điểm các secrets được truy cập ko?
Quảng cáo trá hình =))
Đang Postgres vs MySQL tự dưng sang quảng cáo ServBay ??
Chưa nữa người anh em ơi, hôm trước tui viết dở ở đó xong quên cập nhật nữa, tui đang bận một số project khác 🥹
công nhận là xử lý đc bài toán routing này khá là chuối, nhưng chúng ta nên chọn giải pháp sao cho phù hợp với business của từng người mình nghĩ là cũng oke rồi, ko cần cover hết mọi trường hợp ko cần thiết.
Với cả nếu xử lý được routing thì sẽ dễ hơn nhiều để ta đưa các app đang là standalone vào kiến trúc MFE:
Thực tế khi mình làm MFE thì mình lại thấy App view cũng phổ biến ko kém Widget view, rất nhiều team họ có app sẵn và thường họ sẽ chỉ ok dùng MFE nếu kiến trúc support routing cho họ
Cá nhân mình thấy việc xử lý routing trong các micro-frontend là rất khó khả thi vì với mỗi micro sẽ áp dụng các thư viện khác nhau rất dễ chồng chéo và ko kiểm soát đc. Với routing hoặc các thứ khác liên quan tới trình duyệt mình sẽ luôn đặt ở root app. Các front-end chỉ cung cấp phần UI và 1 số thứ khác liên quan.
VC bạn chính là Mai Lam trong bài viết ha
có bài sau về optional chưa bạn ơi
Về cơ bản cách dùng vẫn vậy, tối ưu về hiệu năng hơn
Bài viết chi tiết quá. Cảm ơn bạn nhìu :>
Mời cười nhưng content không có gì để cười 😜
Kiến trúc Microservices là một khái niệm hot. Đó là lý do mình sẽ mày mò nghiên cứu và up bài lên đây!
Cùng theo dõi series này của mình và góp ý thêm những nhận xét nhé!