2020年8月30日 星期日

資安 | Cloud Platform Security Checklist

 

隨著近幾年AWS 與Azure等Cloud platform 被大量的使用,Peggy 有機會接觸到比較多相關的IOS 認證與security practice。

這些Practice 還蠻重要且實際的,最近花點時間盤點整理如下,給有需要的朋友參考。

這些主要是從相關專案接觸過的部分收集與整理,可能還有其他不錯的Practice 沒有涵蓋在內,也歡迎討論。

以下為各個類別的practices...

Access control 

  • Suggest to integrate with AD
  • Suggest to enable MFA (Multi-Factor Authentication) 
  • 不同環境不同account.  Ex. production 環境不要Dev 的一樣
  • Production 環境裡admin 權限只給 manager 和leaders
  • Do not save credentials in code or instance data
  • Console access: only for necessary members.
  • Review account list for leaving or transfer to the other team regularly
  • In AWS, use VPC Network ACLs or EC2 security groups to control inbound access to instance.
  • least privilege principle
  • Can Not access instances’ OS layer as root user
  • Instead of delegate through credentials, leverage roles is better

Encryption 

  • Enable Cloud Service built-in encryption features. 
    • For example, server side encryption for storage in AWS
  • HTTPS is recommended for all data transmission which include internet and intranet
  • Use Key Management Service provided by Cloud Service (AWS KMS) 

Log Management

  • In AWS,  enable CloudTrail in all regions. 
    • Based on previous experience, S3 access log is not enough. Some logs may be missed.
  • Audit logs must be enabled and keep for at least 5 years
  • Audit logs : who (account), where( ex. IP) , when , access what


Safe Configuration

  • Should not include plain text secrets as part of the infrastructure as code.
  • Review and remove unnecessary/not used features
  • Do not put company's proprietary code to external public storage

Incident management

  • All incidents must keep evidence and report to InfoSec immediately

Other practices... 

  • 滲透測試 (penetration test)
  • Vulnerability Assessment
  • Code scan : ex. Fortify
  • Service architecture design Review
  • DeepSecurity agent in service server ( 敝公司產品)
  • Only turn on Bastion when necessary
  • Information security requirements and specifications should be considered for new features or product development.





若有您轉貼需求,請來信討論。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用,請註明原文標題、連結以及作者。

2020年8月11日 星期二

學習筆記 | 色鉛筆兩三事 ( 雲朵飄飄飄)



今天練習的主題是常拿來點綴天空的雲朵。
主要有三大步驟,雖然看起來不難,不過實際畫起來還滿需要細心調整的,不然很容易畫出傳說中“發霉的雲” 😓 .......

以下是阿金老師的教學,以及Peggy順手記錄的一些細節。

Step 1 : 用捲畫的筆觸來畫出雲的形狀。
  • 形狀要橢長型比較可愛,雲的外型每一個幅度有大有小較好看。太過對稱會很像菠蘿麵包XD
  • 如果很沒信心一次畫出喜歡的輪廓,可以先輕輕地把雲朵的外輪廓先描繪出來
  • 一區一區畫好再畫下一團
  • 雲的兩端處不要拉太尖或太長

Step 2 : 上水筆打底色(可省略此步驟)
  • 將色料均勻往外推
  • 同時可以做出分層的效果
  • 如果對雲的外型不滿意的,可以在這個步驟做點調整。

Step 3 : 混色
  • 先用Step 1的原色在左邊區域做出漸層的效果
  • 再用第二色在右上方畫上一點漸層的效果
  • 最後左下方上第三色
  • 重點在筆觸要「」與作出「漸層」的效果,選色用淡色系較合宜。
  • 疊色小秘訣 :先從邊框一點一點的疊色,時時停下來觀察是否還需要延伸色塊區域?比例是否看起來舒服而不至於太突兀?
  • 選色小秘訣  : 用粉紅或粉橘做出彩霞的效果還蠻好看的。但粉橘不是很好控制,畫不好容易感覺髒髒的,建議先上粉紅色系較佳。
  • 糟糕!不小心疊得不好怎麼辦? 可以稍微用橡皮擦輕輕擦拭,作微調整。
以下是各階段的圖,供大家參考。







///
附上阿金老師的 FB <無敵鐵阿金,變身 > https://www.facebook.com/pukim815 ,裡面有許多老師溫暖風格的畫作可欣賞。


若有您轉貼需求,請來信討論。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用,請註明原文標題、連結以及作者。

2020年8月5日 星期三

筆記 | OKR 實戰學習筆記 1 - 如何開始踏出第一步?







Peggy的團隊採用Scrum 開發流程,目前每一個sprint是兩週。OKR 是一種敏捷工作法,結合OKR 和 Sprint ,就會呈現以上的步調. 


以下是關於怎麼進行每個階段的參考筆記。

準備階段


  • 重點也要放在回答團隊成員的疑惑。例如,為什麼我們要用OKR?它對本團隊帶來什麼具體價值以及可能的變化?因為採用OKR,哪些運作方式 / 流程會有改變?等等
  • 先有個讀書會一起討論也是蠻好的方式。
  • 空出 OKR腦力激盪會議的時間,第一次進行workshop的團隊最好至少留一整天的時間。第一次進行建議找leader一起草擬 OKR version 1。
  • 第一次進行先不急著找相對應的專業軟體/工具,建議以團隊習慣的方式當基礎來延伸。
    • 例如,原本習慣用Kanban,就在旁加上OKR的部分即可。
不清楚什麼是OKR? 可參考此篇


OKR Plan Meeting

Meeting Agenda

  • Discussion of Objectives 
  • Discussion of KR of each objectives


I will achieve (Objective), as measured by (Key result) ... 我希望達成(目標), 通過(關鍵結果1至關鍵結果5)來實現。

腦力激盪過程可思考我們的顧客是誰?我們為其帶來什麼核心價值?等問題。

OKR 分為承諾型和挑戰型:Google OKR 中,完成率達70%(亦即0.7分)就算成功了— 登月文化(鼓勵挑戰的文化)

一般以季度作為單位,設定季度OKR。建議先制定年度策略OKR ,此OKR 可當作公司年度策略的精簡版,接下來進行季度OKR plan meeting. 

對於第二季度之後的OKR plan meeting ,需討論是否沿用上一季的 Objective 或者需要調整,甚至因為時空背景改變而 drop之前的 Objective。


描繪Objective: 用有時限、用字精確、能激發團隊的字句,來描繪團隊共同想像的前景。

在制定KR的過程中,必須問自己與團隊一個問題—這樣的KR完成後是否可以達成目標?強迫思考。

KR 最多三個。

保持透明!具有團隊共識的OKR需公告在團隊可隨時看到的平台上。

關鍵成果類型
  • 基準型:沒有指標可以反應重要目標。例子,取得線上優惠券兌換率的基準。
  • 正面指標:設立“越多越好”的指標目標。例子,每一封寄出的電子郵件帶來的營收增加10%。
  • 負面指標:設立“越少越好”的指標目標。例子,請款處理時間從兩週減少到一週。
  • 門檻值目標指標:設立指標的目標範圍。例子,顧問利用率保持在 70% - 80% 間。
  • 里程碑:成果無法用指標表達。例子,發布推撥通知功能。

SMART Principle to check KR

Specific 具體的
  • 團隊成員對文字表達是否有不同解釋
  • 是否能提供行動指引/策略
Measurable 可測量的 
  • 能否進行定期追蹤
  • 能否清晰的評分
Attainable 可達成的
  • 是否具有挑戰性
  • 是否有實現的方法和可能性(信心指數一般不低於50%)
Relevant 有相關性的
  • 是否有指定Owner
  • Owner 對結果是否具有很大的影響
Timebound 有明確期限的
  • 是否有明確完成的時間


Review Meeting


OKR review & trace in Sprint Review Meeting. 


OKR progress in this sprint
Plan of next sprint


Obstacle How to improve



持續追蹤、紀錄與溝通的OKR 才有價值! 
盡量整合現有的報告、會議。
可接受調整。


Quarter End review meeting

Meeting Agenda

  • leaders share quarter OKR results.
  • Vote for each KR scores 
  • Discussion for Did good/Obstacle/How to improve

KR 評分

Score
Definition
1.0Achieve challenge goal.
0.7Not achieve challenge goal but achieve expected goal
0.3Not achieve expected goal
0Not acceptable, Not finish 
  • 評分: 要簡單,建議按照 0~1.0區間進行評分。
  • 以平均分數為最後結果


Key Result
目前完成狀況
Score
KR1: xxx

KR2:





Score
Thinking
1.0
  1. 關鍵成功因素?
  2. 目標是否設定過低?
0.7
  1. 差距在哪裡?
  2. 可提升的空間和可能性有多大?
0.3
  1. KR 是否有問題?
  2. 工作方法是否有問題?if yes, 找到它並提出改善方案
  3. 是有否resource方面的問題?需要怎麼調整?
  4. what else?....
0
  1. 為什麼?
  2. 這個目標是否還要繼續?

Key point in OKR quarterly review meeting

  • 注意KR完成但O沒有完成的情況
  • 區分OKR類型:承諾型→ 深入討論原因。挑戰型→ 更要鼓勵
  • 著重分析未來可以改善的點,而非「追究責任」
  • 鼓勵團隊發言溝通討論



//// reference

在閱讀完 <<  OKR : 做最重要的事  >> 一書之後,有了概念,但對於怎麼開始還是有些疑惑,因此陸續購入以下相關書籍做為參考。

本篇部分內容也出自以下參考書籍。
  • 執行OKR 帶出強團隊
  • 最快最短完成目標的OKR圖解實踐版
  • OKRs執行力




若有您轉貼需求,請來信討論。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用,請註明原文標題、連結以及作者。

Peggy的實驗空間| 小書庫 Index card ( 讀書筆記總目錄 )

  一直很喜歡閱讀,也常從閱讀好書中與讀書會得到許多的力量與啟發,不管是在人生的低潮抑或是順遂的時候。在閱讀之路上,這幾年也保持一個習慣。當閱讀到喜歡的書籍,且那陣子時間允許,就會提醒自己閱讀完後整理出心得筆記。一方面藉機鍛鍊寫作肌肉與思路,方便之後的複習和查閱。另一方面,也可以...