Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the ultimate-addons-for-gutenberg domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /opt/bitnami/wordpress/wp-includes/functions.php on line 6114
August, 2024 - 八寶周的研究小屋

Month: August 2024

0. 前言


在遊戲中加入音訊不只帶動遊戲感,如果加上劇情對話還能帶來劇情張力並引導遊玩速度。

透過 /playsound,趕緊看看如何透過生成工具簡單達成以上的目的吧!

1. 重點


該指令是在地點觸發,不會隨著物體移動
音量的 volume 參數在 > 1.0 的情況去 x16 則代表是傳聲的距離,最小傳聲距離是 16 格
最小音量是指傳聲範圍之外的常態音量,而非範圍內的最小音量

2. 內容


2.1. 解說 – 指令的整體架構

關於 /playsound 的架構也不複雜,但最基本的情況下建議還是使用以下方式,因為在正常情況下我們是從某個地點或物體去發出聲音,所以 Selector 的設定相對重要。而如果製作的地圖中有版權音樂或音效,要讓直播者避開風險,通常建議放在 music 或 record 兩個相對較少人開啟的音軌。

Python
/playsound <聲音特效> <音軌> <SELECTOR>

而除此之外還有一系列的參數可以調整,首先 /playsound 該指令是在「位置」進行傳聲並非跟著物體移動,因此自由活動的情況下並不適合長篇的音檔。音高的部分在 Java 版能從 0.5 ~ 2.0,上下 1 則代表是八度音的距離,而提高同時會讓聲音變得急促,反之拉低會讓音訊延長。

而 volume 的設定從 0.0 ~ 1.0 是調整音量,但超出 1.0 後則會 x16 代表傳聲的距離,而傳聲的最小距離就是 16 格,而在傳聲範圍內離發聲地點越遠漸弱。末端的 minVolume 從 0.0 ~ 1.0 的數值實際上是在撥放範圍之外,玩家所能聽到的音量。所以假設 minVolume = 1.0 的時候,在超出撥放範圍外的音量反而比在圈內外圍還大聲。 這時候最好的限縮方式就是透過 Selector 搭配 distance 標籤進行塞選。

Python
/playsound <聲音特效> <音軌> <SELECTOR> <x> <y> <z> <音量/距離> <音高> <圈外音量>

2.2. 實作 – 為材質包導入自訂義的音檔

在影片中我們有稍微帶過以下這些可用的介面化工具

【音效】Stable Audio, Meta Audiobox

【語音】TTSMaker

那這邊額外補充幾個工具給具有 Python 經驗 + GPU 的朋友

【音效】AudioLDM2, Stable Audio Open

【語音】speecht5_tts

這次需要用到在 versions 檔案看不到的材質包屬性,首先將 .ogg 音檔放入到 sounds 資料夾目錄之中。

另外建立一份 sounds.json 並進行編輯,這份檔案才是實質標註音訊的設定。各位可以參考以下的格式達成最基礎的設定,最主要會要設定 Sound Event ( 識別字串 ) 以及 name ( 檔案路徑 ) 。關於 stream 的串流設定建議設為 true 避免讀取完整大檔導致的 lag 。

Python
{
    "識別字串": {
        "sounds": [
            {
                "name": "檔案路徑",
                "stream": true
            }
        ]
    },
    "speeches.opening": {
        "sounds": [
            {
                "name": "rpg:speeches/opening",
                "stream": true
            }
        ]
    }
}

完成之後來到我們的遊戲之中,裝上材質包,最好再按下 F3 + T 重整一下。此時我們輸入指令應該要能看到我們自訂義的音檔,並可以正常進行撥放。

2.3. 實作 – 將 MIDI 轉為音階盒樂曲

我們透過 Open Note Block Studio 去讀取 MIDI 並轉換成音階盒格式,導入的時候麻煩維持 1x 並記得勾選 Read Note Velocity 進行音量調整。

這邊提供範例使用的千本櫻 MIDI 音檔

完成讀取後,由於通常公開的 MIDI 都已經調整好設定了,我們就透過 File >> Export as datapack ,等待一段時間直到有個視窗彈出才算完成。

接著我們就能將 musicbox 這個資料夾移到我們自己的 Datapack 之中,此時記得將 load 與 tick 添加到 minecraft / tags 的兩份設定之中,最後記得若為 1.21 記得將 Namespace 底下的 functions 改為 function 該新的名稱。

完成後就能到遊戲 /reload 開始測試,我們主要操作就是 play (撥放), pause (暫停), stop (停止) 上述三種,各位能注意影片中的記分板數值。

3. 後話


快速複習下本篇內容,指令的架構與基礎,再來添加自己的音檔,最後轉換 MIDI 並轉為音階盒樂曲。

那下次我們終於要進入到 Ground Crafting,透過 execute 製作視覺化的合成效果。

4. 參考


[1] sounds.json 格式 — Minecraft Wiki
https://minecraft.wiki/w/Sounds.json

[2] playsound — Minecraft Wiki
https://minecraft.wiki/w/Commands/playsound

  • MC 煉金工藝 – 粒子效果與旋轉法陣

    MC 煉金工藝 – 粒子效果與旋轉法陣

    0. 前言


    無論是在冒險地圖中製作生動的場景,或是為技能設計絢麗的動畫,/particle 指令都能派上用場。透過粒子效果可以大大提升遊戲的沉浸感,讓你的創意在遊戲中得以充分展現。

    那我們這篇我們會進行 particle 的基礎知識到進階設定,順帶簡單實作,馬上就來看看吧!

    1. 重點


    delta 用於指定粒子效果的範圍,並受 count 影響進行排列
    delta 在 count = 0 時通常用來指定 Motion
    force 不僅是增加視野距離,還可強迫在 Minimal 設定之下顯現粒子

    2. 內容


    2.1. 完整解析

    2.1.1. 粒子效果的特性

    在遊戲中粒子效果是以 2D Sprites 形式呈現,因此無論玩家如何移動它們總是面向玩家。而在短暫的動畫過程中可能會變換大小和旋轉,並去循環 Sprite 動畫。

    多數粒子是可以穿過牆面的,而部分粒子(ex: 煙霧)則與實心方塊碰撞,並在蜘蛛網中會被減速,但它們並不受其他實體的影響。

    另對於遊戲機制有影響的粒子效果基本還會顯現在 Minimal 設定之下。

    Sprite

    Sprite 是電腦圖形和遊戲的術語,指整合到場景或環境中的 2D 圖像或動畫。通常由多張不同動作的圖片組成循環動畫,避免遊戲角色在螢幕平移的滑稽情況,且可透過越多的禎數提供流暢的動態感。至今仍大量運用在 Platform, 2D RPG 等平面遊戲,到了 3D 則多都改由骨架進行控制。

    圖片來源: Sunny Land on itch.io
    2.1.2. 粒子效果的生成

    簡單認識粒子的特性後,我們就能夠進一步開始透過指令進行更好的調整囉。

    那由於涉及視覺設定上的觀感設定,我自己基本不會使用最基本的語法,能調整的太少了。

    Python
    /particle <particle_name> ~ ~ ~

    那另外一種較詳細的寫法中,我們能夠進一步調整粒子的數量, 呈現範圍, 速度, 視野距離, 強制顯示, 可看見者,相對有非常多的調整。

    Python
    /particle <particle_name> ~ ~ ~ <delta> <speed> <count> [force|normal] [viewers]

    在座標後方各位千萬別依照 Hint 乖乖地輸入座標。

    這個 delta 區塊主要用來表示要呈現粒子效果的區域,而其中心區域就是我們前面指定的座標。而這邊的數值被放大了 8 倍,所以想要呈現在一格之中我們則要設置為 .125 .125 .125,而後方的 count 除了影響數覺效果外還能用來辨別例外。

    接著先跳過來看 count 也就是粒子的總數,最高可到 32 bit 但前提是你的電腦承受的住。正如我們在 RPG 地圖 Boss Fight 難免遇到粒子效果造成的當機攻勢,生成越多粒子往往對玩家是種負擔。

    而粒子會在 delta 的範圍內隨機擺放,以下為從左到右的指令範例。可以發現即使再多的粒子在同個地點也沒有多少用處,而在 delta 的直徑範圍內除了縮放外還能針對樣式做調整。

    Python
    /particle flame ~ ~3 ~ 0 0 0 0 100 normal
    Python
    /particle flame ~ ~3 ~ .125 .125 .125 0 100 normal
    Python
    /particle flame ~ ~3 ~ .125 .5 .125 0 100 normal

    但在 count = 0 的時候不是沒有粒子,在此時的 delta 則等同於 Motion 設定,配合 speed 從隨機擴散變為直線射出粒子。

    針對音階符與 entity_effect 則用來決定粒子的顏色,色彩數值由 delta x speed 進行計算。

    那 speed 概念正如其名代表粒子的移動速度,但其活性視粒子效果反而不同。在下方的範例中分別是速度 0 與 0.05 來呈現火焰,可以看到在 0.05 的狀況下火焰就已經明顯向外擴散。

    但也不是說速度越高一定越糟,有些比較遲鈍或會下墜的粒子效果反而要到 1 才會變平常所見的樣貌。

    另外當然也有完全不受影響的案例。

    後方兩項都是選填的針對玩家的顯示設定,本身的預設值分別為 normal 與 @a ,但我自己習慣上還是加上 normal 提醒自己這邊還有參數可以設定。

    在 Minecraft Wiki 之中雖然只寫到 normal 與 force 用於顯示於 32 或 512 格之距離。

    但 force 還可強制在 minimal 設定下也看到效果,適合針對地圖製作中必要的元素避免影響遊戲。

    最後尾端的設定則常用於遊戲分組的時候,比如殺手或間諜能夠獨立看到特殊的機關進一步幹些壞事。以下範例以 tag = viewer 進行呈現。

    Python
    /particle flame ~ ~3 ~ .125 .5 .125 0 1 normal @a[tag=viewer]

    2.2. 實作體驗 – 旋轉法陣

    2.2.1. 活用工具

    首先到 GitHub 下載【該工具】,麻煩注意系統需求的部分,各位可能還要額外安裝 .NETCore 3.1 才能執行。

    接著我們能夠到【該網站】下載圖檔,習慣性按下 Preview,接著依照以下設定。

    簡單講解下齁,我們首先設為相對座標,這樣法陣才能夠進行旋轉。而為了放在地面則設為 Z-X 。接著將法陣對齊中心,並取消 Autosize 直接設置直徑為 4 。

    接著開啟 More Settings 調整粒子效果,那範例這我使用的是附魔文字的 enchant,並且將顯示設定改為 normal,就可以輸出 mcfunction 。

    接著到專案目錄進入 functions 目錄之中,複製與檔名相同的檔案。

    2.2.2. 指令測試

    接著貼到我們的 Datapack 之中做成 function 在遊戲中進行使用。那方便起見我們就偷懶用下指令方塊進行測試。

    我們首先準備一個 Repeat 指令方塊,讓盔甲座持續的旋轉。

    Python
    execute as @e[type=minecraft:armor_stand] at @s run tp @s ~ ~ ~ ~6 ~

    接著在後方接個 Chain 指令方塊,在盔甲座底下秀出魔法陣。

    Python
    execute as @e[type=minecraft:armor_stand] at @s run function |YOUR_FUNCTION|

    大功告成!會旋轉的法陣就是如此簡單,對於地圖擺設或技能特效都十分實用。

    3. 後話


    靈活運用這些粒子效果,你可以創造出極具視覺衝擊力的場景,並將你的想法具象化為動態效果,讓你的 Minecraft 創作更上一層樓。

    那由於篇幅關係,我們將 /playsound 拆出額外進行解說,另外也有準備額外實作進行音樂的添加,各位可以期待一下。

    4. 參考


    [1] Commands / particle — Minecraft Wiki
    https://minecraft.fandom.com/wiki/Commands/particle

    [2] Image Particle Generator – by Legitmoose
    https://www.youtube.com/watch?v=1DjAt-WuJFA

    5. 額外


    [1] Animated Particle Plotter – by Cloud Wolf
    https://www.youtube.com/watch?v=YFDo5Inn7x8

  • AWS – Billing and Cost – 計費與預算警報

    0. 前言


    隨著企業越發依賴雲端服務,管理和優化雲端支出的重要性也日益增加。

    而 AWS Billings 為用戶提供了一個全面而透明的計費管理服務,使用戶能夠清楚地了解其 AWS 資源使用情況,並作出明智的財務與優化決策。

    1. 重點


    AWS 在每日進行計費
    預算警報可設置在超出特定數值與 % 之時通知
    AWS 在每月三號收費

    2. 內容


    2.1. 開銷報告

    我們租賃 Amazon 機器總該付錢的,那我們又該到哪邊檢查呢?我們又如何知道哪個服務最燒錢呢?

    2.1.1. 開銷總攬與基礎設定

    我們從用戶的設定選單中我們找到 Billings 並進入介面。

    此時系統會將我們導引到成本管理的介面,這邊我們能快速看到這個月目前與後續預測金額,以及與上個月的比較。若我們想看到過往紀錄與細項服務的使用情況則必須到 Cost Explorer 進行。

    接著在左側選單找下 Cost Explorer,此時作為新帳戶的各位可能還沒有任何資料,會顯示藍色的提示框請 24 hr 後再嘗試。

    這邊我們可以調整統計時常以及統計時間,那預設情況只能顯示 1 年內的資料。而現版本的預設狀態好像是半年以月統計(我剛接觸的時候是單月每日)。此時滑鼠移到圖表上會顯示該間距各服務的花費。這邊要注意 Hourly 的資料採集是「付費功能」,沒有即時需求就不用開通!

    這邊我也順便訴苦下,可以看到維持我這 Blog 的 Lightsail 服務在 2024 五月後由於加收 IPv4 費用漲價了,各位不給獨自營運的我個好評嗎?

    要顯示到最久 38 個月的話我們需要開啟額外設定,必且 1 年以前的資料是指能開啟 Monthly Basis 的。那反正該功能是免費的我是習慣性開啟拉,畢竟比起到信箱調閱每月的帳單來的快速。

    完成設定後記得到頁面下方壓下 Save preferences 才會儲存設定喔,那這邊在處理期間是沒法做修改的。

    2.1.2. 給予子帳戶權限

    但在預設情況下所有子帳戶都是沒有權限瀏覽的。

    此時能夠在 root 帳號調整設定,變更為擁有 IAM 權限的母子用戶都能夠操作。

    進到資訊介面後我們往下滑,找到 IAM user … to Billing information 並將其開啟。接著重新

    等它生效要一段時間,可以先去樓下裝杯咖啡再回來啊 ~ 接著就是瘋狂地刷新。

    2.2. Free Tier 用量

    這邊我順道為新 AWS 用戶介紹下,同樣在 Billings 中的左側選單找到 Free Tier 進入介面。這邊會顯示你目前使用那些能折抵的服務,以及目前的使用量。

    詳細的資訊可以到【官方介面】進行了解,另外要注意有些是全年或每月統計。

    2.3. 預算警報

    阿我有 Free Tier 折抵我的費用,真的有需要擔心破費嗎?關於錢的事自然不能馬虎,但不乏疏漏的時刻。這邊案例是我在自學過程中就曾發生過操作失當多噴了近 15 USD 。

    假設當時我沒有設定警報,還是在月初的情況,我那個僅 30 日的試用不但浪費掉,此時用 26 日的 9 USD 隨意算一下,還要多付高於 270 USD,你說重不重要?

    預算警報主要有兩種作用,一種是當費用破表時寄送信件通知用戶,而另一種則是在超過 N% 的時候。

    2.3.1. 設置警報

    進到 AWS 介面之後我們就點擊用戶名稱開啟設定選單,這次選擇 Billing and Cost Management 進到關於花費的設定介面。

    在左側的選單我們下拉在 Budgets and Planning 找到 Budgets,接著進到該介面之中。

    首次進到頁面之中大概是這種版面,我們看向右側並壓下 Create a budget 按鈕。

    這邊我們選用 Advanced 進行建置不然少了許多功能。接者選擇針對開銷的 Cost budget 並進下步驟。

    我們就先不管右側的 Budget Preview 並關閉,這個視窗主要的用途只是讓我們去評估後續的預測。關於名稱的設定就自己能懂就好,這便範例就使用 10 美金作為界線。

    下面我們維持預設按月統計。而其底下的 renewal type 則是說該預算警報的形式,是無限期的重複啟用,還是有時效性的(專案)預算。

    從何時啟用我們也先不動,預設就是從本月開始計算。至於金額規則我們使用 Fixed 並固定為 10 美金。

    我們這邊同樣保留預設去統計所有 AWS 服務之支出金額。

    進到下個步驟我們新增門檻。

    範例這邊我們設為 Actual 的 80% 時會寄信到指定信箱,而 eMail 通知最多支援十人,否則就要倚靠另外兩個方式進行建立。

    而除了 Actual 還有 Forecasted 的觸發方式,相對提早預估異常的發生,但在月底的時候也很容易誤觸。

    再來就是過往沒有的功能,我們實際上還可以設定當觸發警報時會去執行甚麼動作。透過 IAM Role 給與權限去調整 IAM Policy 或者關閉 EC2 與 RDS 的 VM 資源。

    我們就先不操作這塊進入下步驟。

    再度確認一切設定,完成後就可以進行建立,如此當隔日計費時超過 8 與 10 USD 時都會寄送警告信。

    3. 後話


    初步觀察 Cost Explorer 後更能知曉與預測後續的花費,並結合 Budget 提醒用戶發生評估之外的異常狀態。但在參加取多官方活動時拿到了不少的折抵券,我們又如何進行兌換呢?

    下回快速的來看看吧!

    4. 參考


    [1] Grant access to the billing console – AWS Doc
    https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-set-up.html

  • AWS – Identity Center – 分配組織帳戶與 Single Sign On

    0. 前言


    在組織間需要確保其應用程式和資源的訪問既簡便又安全。為解決過往 IAM 的管控問題與 AWS 本身沒有專案設計的問題,Identity Centre 提供了一個集中化的平台,簡化了身份和存取管理。

    1. 重點


    能夠邀請非 AWS 用戶使用組織的 AWS 帳戶
    除允許用戶登入到主控台外,還能夠綁定 SaaS 應用
    登入用戶擁有 Session 連線時長限制,並會刷新一組 Access Key

    2. 內容


    2.1. 關於 Identity Centre

    AWS IAM Identity Center(前稱 AWS SSO)是一項由 AWS 提供的身份和存取管理服務,幫助企業管理雲端和企業應用程式的用戶訪問並確保安全和合規。其支援並可自由替換 SAML 2.0 之 SSO 驗證商,也不用擔心系統轉嫁的議題。

    而 SSO (Single Sing-On) 的是讓使用者一次性針對多個應用程式和服務進行驗證的方法。其概念在於使用者只需在單個登入介面驗證就可以使用多個應用程式。

    生活案例

    現今越來越多的餐飲店引入 LINE 掃碼點餐,此時用戶的資料收錄在平台提供商的資料庫,此時可以依靠你的 LINE 帳號進到同供應商底下的其他餐廳進行訂餐,不用另外註冊新的帳戶。

    IAM Identity Centre 接手管理 Organization,在組織中不同於 IAM 直接將權限配給 Group / User,反而是在分配帳戶時才綁定權限,以此來避免管理員忘記過往的群組配套權限而造成失誤。透過該方式允許的用戶能透過 Portal 登入後進行多支子帳戶的管理。

    2.2. 建立組織與成員

    雖然說組織除了配與權限外還能透過 Applications 給予 SaaS 的服務權限,但設定上有不少步驟,我們今天就專注在權限的設置。

    2.2.1. 建立組織

    我們首先在搜尋欄中查詢 IAM 並找到 Identity Centre 並進到其介面之中。

    在 Identity Centre 中首先會需要建立一個 Organization,而此時選擇的地區也就是之後的總部位置,那為了降低網路上的連線延遲,請確保所在地區為日本東京(2025 年後者可考慮 Asia Pacific (Taipei) 臺北地區),因為建立之後我們是沒法輕易改變組織區域的。

    此時會跳出一個視窗要你選擇模式,我們維持預設即可,右側的主要是給企業做為體驗,可以看到許多功能都沒法使用。

    再來稍等他介面生成一段時間,完成之後就會導到主控介面了。

    此時若我切換到其他 Region 就會跳出錯誤的訊息並無法進入管理介面。這邊表示很清楚組織只能存在於一個地區,若要遷移的話我們必須先「刪除」再「重建」。

    2.2.1.1. 更換 Portal URL

    在預設情況下 Portal URL 由一組亂數的 sub-domain 組成,那我們實際上是可以自行修改 sub-domain 的分支名稱的,在 Settings Summary 中找到 Portal URL 並按下 Edit 。

    這時會跳出一個視窗,我們只要將想要的名稱輸入格內並重複確認即可。但這邊很重要!一旦修改過後就無法變動了,只能整個 Organization 重建或透過自己的 DNS 做 CNAME 轉接,各位請好好考慮。

    2.2.1.2. 替換 Identity Provider

    我們講到該服務系統本身支援 SAML 2.0 的 SSO 提供商,有需求的就這邊來看下怎麼替換。

    那當然事後若你相信或想整合在 AWS 的系統也是可以換回的。

    2.2.2. 建立成員

    我們有了組織之後總要新增些成員,我們進到 Users 分頁並於右上方壓下 Add user 新增 User 。

    基本每次避不開的就是先取資源的名稱,而這邊將會是我們未來慣用的登入帳戶,就交給各位自行命名了。接著填寫受邀請者的 eMail 信箱,這邊不論是否有註冊過 AWS 都可以使用進行使用。

    這邊的屬性除 Username 之外後續都可進行修改,還能透過該方法進行帳戶轉交。

    接著繼續填寫的是受邀請人的名與姓,這邊的 Display Name 是管理員在管理 Organization 時能看到的樣貌,但該用戶登入介面後只會看到 First Name,若想設定為暱稱的話要注意一下。

    這邊提醒下若組織有透過前面提到的 Applications 發配 Office 365,記得需要在 Additional Attributes 中給予該用戶一組用於登入的序號。其餘部分基本就是完善用戶資訊的設定,這邊我們就先跳過,直接點擊 Next 進下個步驟。

    我們後續按階段慢慢來,這邊我們直接先按 Next 進下一步驟。

    接著檢查自己的帳戶設定是否有誤,若完成後就到最底層按下 Add user 新增 User 吧。

    完成之後就能看到新的 User 在介面之中囉,我們在這邊可以看到所擁有的所有 Username,並透過 Display Name 去方便管理人員看說是誰或做啥用的帳戶。那 Status 有 Enabled 自然也有 Disable,我們先接著點選 Username 進入管理介面。

    在最頂端的 General information 區塊就能看到有個按鈕能夠 Disable 用戶狀態,那過程中我們還沒去驗證信箱因此會有回色區塊的提醒,接著就去收下認證信唄。

    來到信箱應該有收到一封來自 no-reply 的 AWS IAM Identity Centre 邀請信件,那我們不疾不徐的原因就在於其效期長達 7 日,那這這信上還會附有帳號資訊與登入連結。接著我們就按下 Accept invitation 接受組織邀請並設置我們的密碼吧。

    那由於我們在建立過程中沒有調整設定,使用預設情境讓收到邀請的用戶自己去設置喜歡的密碼。

    當我們首次為 User 註冊密碼後就會顯示以下建立完成的通知,接著導回到 portal 登入介面。

    我們先嘗試登入這個新的用戶,此時我們會被強迫要幫該帳戶綁定 MFA 設備。

    完成綁定之後我們若登入帳戶進到資源介面,但由於並沒有賦予任何權力給該帳戶因此會是空的。

    2.2.3. 建立 Group

    群組的概念在於其底下的用戶能被快速概括選取以及調整設定。接著在左側的選單中找到 Groups 並在其頁面右上方壓下 Create group 進行建置。

    那在下方的範例我就取作 Admin 作為示範,該群組名稱代表擁有 AWS 所有資源之管理權限。但在過程中各位應該知道我們並沒有配發權限,關於這部分則是 Permission Set 進行處理。

    那後續有需要變更的情況下我們能點擊群組名稱進入管理介面。

    並在這邊進行用戶的補登。

    2.3. 賦予用戶權限

    再來我們就要真正的賦予用戶權限並給予到指定帳戶的管理權限。

    2.3.1. Permission Set

    同樣在左側選單中找到 Permission Sets 並透過右上角的按鈕進行建置。

    在設定過程中我們有兩種配套方法,第一種是使用官方預設的權限組,雖然可以快速建置但會缺乏細粒度調整,我們待會就來體驗另一種。

    我們在頁面的上方選擇 Custom 後進到下一步。

    在這邊怎麼樣?我們又來配置 IAM Policy 啦!這邊有三種方式,包括直接書寫,用戶客製化的以及官方預設的。我們這邊使用預設的並選擇最大的 AdministratorAccess 後進下步驟。另外一樣我們是能設置 Boundary,但我們先跳過並進下一步。

    在這邊我們同樣簡單命名我們的資源為 Admin,那這邊要注意的是 Session duration 代表每次用戶的連線時間,這邊建議各位設久一點,不然操作資源到一半被強制登出肯定滿肚子火。

    而上述的 Replay state 則是用戶登入後該自動跳轉到什麼介面,比如我們使用該網址的話則會自動導引到 US – Ohio 地區並在 EC2 的管理介面上。

    HTML
    https://us-east-2.console.aws.amazon.com/ec2/

    我們接著到下一步驟進行檢查,確認完成後就可以建置了。

    2.3.2. 分派權限

    我們接著就來配與組織用戶到指定帳戶下進行權限的操控吧,首先在左側選單看到 AWS Accounts,這邊彙總覽所有組織擁有的帳戶,但因為我只是一般個人我就只示範操作單個帳戶。

    這邊我們先選取我們要配給用戶(群組)權限的帳號後壓下右上角的按鈕。

    那範例這邊我們就授權給所有在 Admin 群組的用戶,這樣未來我們只用把新的 User 加到群組即可。

    再來勾選我們的 Permission Set,可以看到直到這個步驟我們才配與權限給用戶使用。

    再來下一步就是確認設定,瀏覽無誤後就可以完成設定了。這時會跳出一個提示框說明正在建立,並請用戶不要離開本頁面。稍等一下就會完成建立了。

    完成之後我們回到我們的 SSO 介面並嘗試 F5 刷新,此時是部會有任何結果出現的,因為我們的 Session 仍保持再更新前的狀態。必須登出後再重新登入,此時應該會多出一條資源。

    點選開來之後,左側的按鈕能進入網頁主控台,其名稱由 Permission Set 來決定。而右側按鈕則是生成 “本次 Session” 的 Access Key,相對於 IAM 固定的更加安全。

    進到網頁控制台後我們留意下右上角,應該會是 Permission Set 搭配 Username 的樣式。這樣就代表我們成功的分派 Identity Centre 之帳戶給用戶,完成本次的實作。

    3. 後話


    我們成功分出 SSO 的組織帳戶了,但目前有個嚴重的問題在於預設情況下 Billings 是不公開給子用戶的。那麼我們又要如何啟用呢?順道來設置我們的預算警報吧!

    4. 參考


    [1] What is SAML – Cloudflare Learning
    https://www.cloudflare.com/learning/access-management/what-is-saml/

    [2] Customizing the AWS access portal URL – AWS Doc
    https://docs.aws.amazon.com/singlesignon/latest/userguide/howtochangeURL.html

  • AWS – IAM 架構與用戶分派

    AWS – IAM 架構與用戶分派

    0. 前言


    權限管理一直以來是最重要的議題,攸關安全性與組織性。

    那我們就來看看 IAM 到底如何組成以及如何分派權限吧!

    1. 重點


    IAM 可用來賦予用戶或資源執行權限
    目前官方建議以 Identity Centre 取代 IAM 來建立與管理子帳戶

    2. 內容


    2.1. 關於 IAM

    該服務用於安全管理 AWS 資源的訪問權限,控制用戶是否能訪問特定資源以確保安全和規範。

    在普遍的 IAM 架構我們會有 Policy 去綁定多個 Permission,而我們可以配套給 Group(群組)與 User(個別),另外針對 AWS 服務則是配與 Role(角色)。那在下圖我就配上生活案例搭配解釋。

    而在除了官方預設的 Policy 與 Role 都是可以另外建置的,而 Policy 的架構則主要由 Effect (效果), Actions(操作權限), Resource(資源) 組成,並另外能加上 Principal(對象), Condition(條件)。

    在下方的範例則是表示 “針對所有 Principal 除了 Condition 中的帳戶之外一律拒絕其對指定 S3 Bucket 的任何操作” 。

    Python
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
          "Effect": "Deny",
          "Action": "s3:*",
          "Principal": "*",
          "Resource": [
            "arn:aws:s3:::BUCKETNAME/*",
            "arn:aws:s3:::BUCKETNAME"
          ],
          "Condition": {
            "ArnNotEquals": {
              "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name"
            }
          }
        }
      ]
    }

    那在組織中我們肯定不可能給予每個員工管理員權限,而是給予相匹配的最小權限阻止其讀取與業務無關的資源,甚至盜竊組織重要資源。

    我們就準備示範如何透過 IAM 建立子帳戶來操作 AWS 介面吧。

    事前提醒

    由於 AWS 官方目前建議採用 Identity Centre 來管控組織分帳戶,在下一篇章我們會進行介紹。

    但現今仍不少公司業務為求快速簡便而慣用 IAM 服務,因此以下實作主要用於示範,建議各位實作後進行刪除,或者純看以下的過程即可。

    2.2. IAM Group 的建立

    我們首先進到的是群組的概念,卽在內部的用戶會自動繼承相關的權限。我們從 IAM 面板的左側選單找到 User Groups 並進入介面。

    進到介面後我們壓下右上側的 Create group 按鈕開始進行建置。

    那我們在範例中建立個群組並取作 aws_admin 代表該群組擁有 AWS 所有服務的管理員權限。那目前我們沒有建立任何 User 就先跳過中間的步驟,而權限的部分這邊從簡而選取 AdministratorAccess 套用最大的 Full Access ,完成過後就可以建立群組了。

    建立完成過後我們應該能立即看到在頁面上顯示,就可以進到下一步了。

    2.3. IAM User 的建立

    事前提醒

    由於我事先準備後續教材,截圖的版面可能與各位不同,關於 Identity Centre 的部份請忽略它。

    那接著我們就要進到 Users 介面來準備建立 IAM 帳號。

    直接點擊右上側的 Create user 按鈕進行用戶的建立。

    由於在下一期我們會透過 Identity Centre 來取代建立 IAM 用戶的形式,我們就先隨便幫它取個名字為 tmp_admin 代表是暫時性的管理員帳戶。接著請勾選正下方的 access to … Console 才能讓用戶從官方的登入介面進到網頁介面之中。那這邊為了方便我先取消掉要重置密碼的設定。

    進入下一步看下權限的設立方式,Copy 是從其他 User 複製權限我們就不多談了,這邊來體驗另兩種建立方式:Add to group 與 Attach policy。

    我們先體驗 Attach policy 齁,阿其實就跟剛剛添加權限到 Group 相同的感覺,我們就不多加嘗試了。

    接著我們回到預設的 Add to group,選擇我們剛才設定的 aws_admin 群組。那雖然說同處同個 Group 但實際上我們還能另外設置 boundary 限縮該 User 的權限,但我們就先跳過並進到下一步。

    再來檢查一下設置並按下 Create user 建立新的 User 在 Group 之中。

    建立完成後我們會生成三個資料,這邊直接下載 csv 資料進行保存齁。

    那反正實作完我就會將該帳戶刪除,後續該 IAM 的 Account ID 就懶著遮了。但 Account ID 本身也能用於一些處理因此各位盡量不要洩漏,正如我在先前的截圖中都有遮住 root 的 Account ID 。

    2.3.1. MFA 設置

    建立完成後先別急著測試登入,這邊先帶各位看下怎麼去設定 IAM User 的 MFA 機制。首先點擊 User name 進入到管理介面之中。

    這邊額外說明下,雖然我們是透過 Group 的方式來建立用戶,但在後續我們是可以在此頁面給此 User 新增額外的權限。那總之我們進到 Security 分頁來調整重要的安全設定。

    在這邊我們也能夠取消該 User 網頁介面登入的許可,那這邊就先留意下這邊可以建立 MFA 就好。

    2.3.2. 介面登入

    接著我們複製 sign-in link 貼到瀏覽器後,登出 root 帳戶的 AWS Console 來嘗試當入該 IAM 帳號吧。那這個網址的用途就只是會自動填入 IAM 的 Account ID,也就是連結開頭的 12 位碼。接著輸入我們的用戶名稱 tmp_admin 並貼上在 csv 檔案中的用戶密碼。

    成功進到我們的頁面,各位也能發現在右上角的用戶名稱為剛所設定的 User 名稱就代表完成了。

    2.4. 清除練習資源

    因為相對我們下次要講得方法簡便許多,針對小型案件與臨時權限不少的企業仍採用 IAM 進行配發,因此本篇還是稍微介紹下建立與登入 IAM 用戶的方式。

    但現在 AWS 官方也本身不太推薦使用 IAM 開設子用戶,主要在於 IAM 的管理與授權很常需要變動,且其 Access / Secret Key 申請後不會自動更新,過往造成不少管理的糾紛案件。

    又由於 AWS 本身沒有 Project 的概念,通常都是分出很幾個帳戶作為 Project 進行使用,這樣任何人員都需要好幾把金鑰去應對不同的公司帳戶。

    後續我們將採用 Identity Centre 去結合 Single Sign-On 的優點來進行帳戶的分立,那我們接著重新登入我們的 root 帳戶,來把剛練習的資源都砍砍掉。

    我們首先到 Users 介面勾選 tmp_admin 並點選 Delete 依照操作進行 User 的刪除。

    接著再來到 User Groups 同樣勾選 aws_admin 並透過 Delete 依照操作進行刪除。

    如此我們就移除乾淨本篇有異動並稍有安全風險的資源囉。

    3. 後話


    簡單的認識 IAM 其架構與建立子帳戶的方式,但當組織龐大的時候越來越難管理又還可能員工要領好幾把鑰匙。甚至是員工或顧客不想辦理 AWS 帳號。

    那針對這個議題 AWS 後來就推出了 Identity Centre 並結合 SSO 進行快捷的單一登入,並方便組織進行分帳戶的組合管理。那我們下期就來看看又如何從組織分配帳戶呢?

    4. 參考


    [1] How IAM works? – AWS Doc
    https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html

  • AWS – 設置多重要素驗證(MFA)

    0. 前言


    相信不少人註冊完 AWS 的全新帳號就迫不及待去體驗各種功能,卻不曉得忽略了帳戶的安全性。

    在我們分出子帳號之前我們首先就來保管好我們的 root 帳戶。

    1. 重點


    透過 MFA 可以加深別人破解的可能性
    不論是母或子帳號都建議加上多重要素驗證

    2. 內容


    2.1. MFA 的概念

    MFA (Multi-Factor Authentication) 是一種要求使用者除了輸入密碼以外還要輸入更多資訊的多步驟帳戶登入程序。其用意於透過只有用戶個人手頭擁有的其他方法來驗證用戶的身分。

    (圖片來源:Post by Michael Mardahl

    2.1.1. MFA 的優勢

    降低安全風險

    MFA 可最大限度地降低因人為錯誤,密碼錯放和裝置遺失而導致的風險。

    改善安全回應

    公司可以設定多重要素驗證系統,以便在偵測到可疑登入嘗試時主動傳送提醒。這有助於公司和個人快速回應網路攻擊,從而減少任何潛在的損害。

    2.2. 如何設置 MFA

    假設我們今日剛進入到管理介面,此時我們點擊右上角的用戶名稱打開設定選單,接著選擇 Security Credentials 之設定並跳轉至頁面之中。

    進到介面之後稍微往下滑,而 MFA 設定就在 Account Details 的下一格也足見其重要性。我們接著點選該區塊右上角的 Assign MFA Device 快速來設定我們的多重要素驗證。

    最開始很直覺的就是為你接下來要設定的 MFA 方式命名,那後續驗證方式我將用簡易又常見的驗證器,範例使用我自己長年累積的 Authy (以前支援電腦跟手機,現僅支援手機)來命名。那另外幾個常見的軟體還有 Google Authenticator 與 Microsoft Authenticator 。

    完成後我們進到下一步,這邊我們在步驟 2 按下 Show QR Code 以顯示我們的 QR-Code 並且透過程式掃描添加到帳戶。添加完成之後應該會看到一組 6 位數字密碼他在一段時間後就會自動刷新,接著在步驟 3 輸入 “連續” 兩組數字密碼,輸入完成後趕緊按下 Add MFA 進行建置。

    完成之後我們就能看到首個綁定的 MFA 設備!

    緊接著我們就登出 AWS 重新登入看看,進到登入見面使用剛綁定 MFA 的帳戶登入(範例為 root)。

    輸入完帳號密碼之後就會跳出新一層的 MFA 防護,此時就要開啟我們的驗證器並輸入 6 位數字密碼。而這也代表我們 MFA 有設置成功,各位為帳戶添加一層防護。

    2.3. MFA 方法全介紹

    雖然我們完成建立一種最基本的 MFA 方式,但下方我們還是簡單介紹下所有驗證方式與其原理,讓各位更好的了解並進行選擇。

    2.2.1. Passkey or Security Key

    根據 FIDO 標準後在這個分類中 AWS 支援兩種型態:實體金鑰(硬體設備)與設備同步密鑰

    實體金鑰(Security Key)的概念就很明確,他就是可以插上電腦的一組硬體設施以此作為認證的方式,比如 Yubico 所推出 YubiKeys 系列。你可能覺得這晶片看起來十分脆弱,但這麼重要的東西自然會經過些特殊處理。丟到洗衣機,砸到地上,甚至被轎車輾過基本都能存活下來。

    而他由於規則的約束力,對於網路釣魚驗證有些許防護力,但主要優勢在於電源由插入的電腦提供。

    而設備同步金鑰(Synced Key)多數要連接你的手機設備,可能搭配生物鎖或一些特殊的軟體進行認證。

    2.2.2. Authenticator App

    我們常看到的驗證器是當我們在應用程式中註冊帳戶後,透過 QR-Code 或手動輸入連接碼加入我們的帳戶進行管理的方式。通常在一段時間就會刷新數字密碼,因此也讓有些人認為只有當下那組數字可以執行,但實際上這類程式多數都是能維持 2 組的紀錄,那相信 6 位數字的記憶對各位不難吧?

    (圖片來源:Authenticator in Google Play
    2.2.3. 硬體 TOTP

    TOTP 的全名是 Time-Based One Time Password,我們使用的 Authenticator App 基本都是採這種方式,也就是依靠時間去生成一組隨機性的密碼。

    那硬體顧名思義又是外插並由電腦供電的,但不同於 Security Key 他會有個螢幕顯示數字密碼。並透過驅動軟體來進行驗證。

    (圖片來源:Token 2

    3. 後話


    多重要素驗證其實是不可忽視的動作,密碼設的再長再安全,若被盜錄也毫無用武之處。

    那為了 root 帳戶的安全我們一般會再切出子帳戶來進行日常的操作,那後續我會用兩種方法來達成這個目標。但若使用 Organization 建立的子帳戶是沒權限管理 Billings 帳單的。

    所以在那之前我們先來設置預算警報避免花費爆表吧!

    4. 參考


    [1] What is MFA? – AWS What-Is
    https://aws.amazon.com/what-is/mfa/?nc1=h_ls

    [2] Using MFA in AWS – AWS Docs
    https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html

    [3] We ran over some security keys with a car and some still worked – Freedom of the Press Foundation
    https://freedom.press/training/blog/security-keys-meet-real-world/