日曜エンジニア

仕事・趣味のメモ置き場です。皆様のお役に立てれば幸いです。

クラウド未経験者が365日でAWS認定試験8個全て一発合格するために実施したこと

1年間かけて目標にしていた資格を取りきり一区切りつきましたので勉強内容をまとめてみました。

f:id:ls-ltr:20220101235351p:plain
aws試験取得一覧
利用可能な AWS 認定より抜粋

はじめに

  • ご認識の方も多いと思いますが、AWS認定試験には、認定契約があるため、受験者は試験の設問内容等は開示できません。そのため、どういうことを学び、試験に挑んだのか?を中心に私の個人的見解として記載しています。
  • ベースとなる受験者に必要となるITインフラの知識に大きく影響される試験ではないと個人的に感じていますが、参考に私のスペックについて下記に記載しておきます。(合格だけであれば、基本情報技術者試験レベルの知識で合格は問題なく可能だと感じました)
  • とりあえず、試験の合格が目標。という方へ向けた内容となります。

私について

試験受験履歴

No. コード 試験名 受験日 点数 合否 難易度(5段階)
1 CLF-C01 AWS Certified Cloud Practitioner 2020-12 888 合格 ★☆☆☆☆
2 SAA-C02 AWS Certified Solutions Architect - Associate 2020-12 811 合格 ★★★☆☆
3 SOA-C01 AWS Certified SysOps Administrator - Associate (retiring July 26th, 2021) 2021-01 872 合格 ★★☆☆☆
4 DVA-C01 AWS Certified Developer - Associate 2021-01 833 合格 ★★★☆☆
5 SAP-C01 AWS Certified Solutions Architect - Professional 2021-02 819 合格 ★★★★☆
6 SCS-C01 AWS Certified Security - Specialty 2021-07 921 合格 ★★★☆☆
7 ANS-C00 AWS Certified Advanced Networking - Specialty 2021-10 904 合格 ★★★☆☆
8 DOP-C01 AWS Certified DevOps Engineer - Professional 2021-11 918 合格 ★★★★★

以下では試験名をコード先頭3文字で記載します

先に結論

8回の試験勉強の試行錯誤の結果、効率がいいと感じた学習方法は、AWS WEB問題集で学習しようをひたすら繰り返すことでした。 色々試行錯誤しました、これが一番試験対策としては良かったです。 WEB問題集の問題を解く際に、よくある学習方法ですが、選択肢のどれが正解かではなく、他の選択肢がなぜ間違っているか。 もしくは問題文中のどこからこの選択肢を確定したかを理解して解いていくことを意識しました。 なお、受験申し込みのタイミングとしては、WEB問題集の模試で80%以上正解を答えれるようになったか?を指標としていました。

試験のために課金はしたくない等のご意見もあると思いますが、時は金なり、短期間で集中的に学習し、1発合格して時間を節約し、 合格後に実際に設問で提示されたアーキテクチャなどを実装する手を動かすフェーズに早くシフトするのがトータルで見ると安く済むのかなと考えております。 書籍を買うのと同じような値段です。あと。書籍と異なり利用期限が強制的に限られるため、お尻に火がつきます笑 (WEB問題集の宣伝記事ではないです笑 他ツールや公式ドキュメントなども記載しますのでご確認いただければ幸いです。)

[No.1] AWS Certified Cloud Practitioner

[No.2] AWS Certified Solutions Architect - Associate

 勉強時間

  • 4週間
  • 平日2時間
  • 土日3時間
  • 20日2時間+8日3時間=64時間

勉強方法

コメント

最初にUdemyを実施しました。8つの受験勉強でちゃんと実機を触ったものです。 上記のUdemyのコースは36時間ほど動画を見るだけでかかりますので今振り返ってみると、合格を目標とするのであればマストではなかったのと思います。 私は倍速再生しつつ手を動かしてみました。途中で時間がかかることに気づいたのでセッション10まで実施し、それ以降は通勤の電車等で流し見し、終わらせました。 初受験ということもあり、書籍も使いましたが、WEB問題集だけで良かったですね。 WEB問題集は全問題を2周しましたが、問題数もかなりあるので合格記を参考にしつつ、直近の合格者の方の学習範囲を重点的に学習されると効率が更によくなると思います。 試験は、SAAをターゲットに勉強をしていましたが、試験申し込みの時点で試しにCLFの問題を見てできる感じを受けたので同日にCLFを受験しました。

[No.3] AWS Certified SysOps Administrator - Associate (retiring July 26th, 2021)

[No.4] AWS Certified Developer - Associate

勉強時間

  • 3週間
  • 平日2時間
  • 土日3時間
  • 15日2時間+6日3時間=48時間

勉強方法

  • AWS WEB問題集で学習しよう
    • SOA→最新の問題から過去10セットを1周実施
    • DOA→全問題を1周実施
  • WHIZ LABS
  • AWS公式ドキュメント
    • 模擬テスト

コメント

書籍は検討しましたが、あまり評判が良いのが見当たらず使用しませんでした。 SAA合格後、WEB問題集を軽く解いた感じで、SOAはSAAの知識で充足している。と感じてましたので、SAAの1週間後に受験しました。 試験ガイドを見ても、CloudWatchなどのロギングモニタリングやIaCやネットワークなど幅広く要求されています、SAAと比較するとCLIのオプションなどを問われることもありますが、試験範囲が広いので合格を目指すのであれば、捨ててもいいなという問題も多い印象でした。

DOAは、WEB問題集を1周やり切りましたが、暗記はできたが、内容がわかったという感覚が得られず、 試験受験の前夜にAWS公式の模擬テストを受験しましたが模擬の結果は不合格。。。 当日も答えがわかったというより、消去法でどう考えても当てはまらないものを削ったら気づいたら合格していたという感じです。 模擬試験は、不合格でも結構良い点数が取れていたので拍子抜けしました。 問題の日本語翻訳が良くない問題がちらほらあるので原文(英語)と切り替えつつ問題を解かれることをお勧めします。

[No.5] AWS Certified Solutions Architect - Professional

勉強時間

  • 4週間
  • 平日2時間
  • 土日3時間
  • 20日2時間+8 日3時間=64時間

勉強方法

  • AWS WEB問題集で学習しよう
    • 2周
  • AWS公式ドキュメント

コメント

一番勉強時間をかけた内容でした。 幅広くかつ、サービスを跨いだインフラアークテクチャ設計を要求されるとのことだったので 書籍については私は使いませんでしたが、周りの受験者からの評判は良かったので以下がおすすめです。 AWS認定ソリューションアーキテクト-プロフェッショナル~試験特性から導き出した演習問題と詳細解説~

なお、試験自体は問題が長文な傾向があるため、試験時間ギリギリまで使うことが想定されます。 事前の知識量とともに体力・集中力も求めれますので、試験前日はしっかりと寝ることをお勧めします。

あとは、WEB問題集を解いていると、設問内容と解に傾向が出てきますので、そこら辺もしっかりと押さえておくと幸せになると思います。 例えば。。。( あくまでも、AWS試験ではなく、WEB問題集の問題の傾向を例示しています )

  • IAMのアクセスキーという選択肢はNGな可能性高
  • IoTって記載が問題文中にあった場合は、API-Gateway+Lambdaで受ける選択肢はNG(Rate exceeded)。じゃあどうする?⇨SQS等でキューイング構成を。
  • アーキテクチャ案を考える問題で、間にEC2を噛ませるような回答は基本NG。AWS的にはサーバレスでユーザ側の責任範囲を狭めることを推奨。
  • 性能問題が来たらどこがボトルネックか?を問題文中から読み解く
    • DB→Cash/リードレプリカ/SQS(書き込み量の平準化)
    • APロジック→on EC2からLambdaに変更
    • WEB→静的ファイルをS3へ(.net/phpなどの記載が問題文中にあった場合、ひっかけの可能性あり。動的ファイルありのためS3オンリーにはできないので注意)

[No.6] AWS Certified Security - Specialty

勉強時間

  • 1週間
  • 平日2時間
  • 土日4時間
  • 5日2時間+2日4時間=18時間

勉強方法

コメント

名前の通りですが、セキュリティやガバナンスを支援するサービスが多く出題されています。 AWSではセキュリティをJOBゼロと謳っていることもあり、SAPでもセキュリティに関する知識への理解は問われますので、専門資格の中では一番SAPからの流れで受験しやすい試験かもしれません。 なお、余談ですが、AWS専門資格対策はWEB問題集でも公開されている問題数が少ないため、AI/MLなどの分野は別途補完が必要かもしれません。 (セキュリティはAWS試験前にある程度得意な分野だったので、苦労せず理解しており、あまりコメントがなくてすみません。何か詳しく聞きたい等あればコメントください。)

[No.7] AWS Certified Advanced Networking - Specialty

勉強時間

  • 2週間
  • 平日2時間
  • 土日4時間
  • 10日2時間+4日4時間=36時間

勉強方法

コメント

IPAネットワークスペシャリストのようにネットワーク構成やプロトコル毎のエンペローブ何Byteがなにを示しているか?ということより、 AWSサービスのネットワーク関連サービスの留意点が問われているなと感じました。 セキュリティよりもネットワークの方が各サービスのパラメータについて、BlackBeltで出てくる制限やユーザで設定可能なパラメータは頭に入れておくことをお勧めします。 (SAPを受験している前提ですが)サービス数はそんなに多くないので、暗記が得意じゃ無いって人でもこれぐらいの時間があれば合格は可能だと思います。

[No.8] AWS Certified DevOps Engineer - Professional

勉強時間

コメント

試験ガイドの通り、 この試験はデリバリー・デプロイ・自動化に特化したAWSサービスにフォーカスかつ、プロフェッショナルレベルのためコマンドのオプションなども要求されました。 私がオンプレのインフラ管理の経験がメインだったので、デプロイパイプラインなどに土地勘がなく暗記に徹したため時間がかかりました。 あと、WEB問題集を解いていても、CodeCommitは中身がGitリポジトリですので、Gitに関する知識や、リリース戦略などの一般知識も勉強しました。

AWS Hands-on for Beginners AWS Code サービス群を活用して、CI/CD のための構成を構築しよう!などで試してイメージを掴んだ後に暗記にするのも良いかもしれません。

最後に

私の拙い文章を読んでいただきありがとうございました。皆様の試験準備の参考に少しでもなれば幸いです。 ご不明点等あれば、本BlogのコメントやTwitterでDMいただければフォローします。 公式模試が最近無料になったらしいので試すのもありかもしれません。↓

ななななんと!AWS認定の模擬試験が無料になりました!!

クラメソさん、いつもいい記事ありがとうございます!

AWS SecretsManager マルチリージョンレプリケーションreplicateを試してみました。

はじめに

開発/テスト/本番環境における、RDB接続情報などの環境依存パラメータをよりセキュアに保管運用できるSecretsManagerですが、マルチリージョンでのレプリケーションに対応したということなので、レプリケーション設定および変更した際の伝搬の様子を確認します。また、同時に複数リージョンへレプリカリージョンできるかも確認したいと思います。

参考記事

https://aws.amazon.com/jp/blogs/security/how-to-replicate-secrets-aws-secrets-manager-multiple-regions/

登録手順

  • 1.保存したいシークレットを選択 image.png

  • 2.[シークレットを他のリージョンにレプリケート] image.png 今回は、大阪リージョンと地球の裏側のサンパウロを選択。 image.png

  • 3.登録完了 secretsmanager.png

結果:aws cliでキーの値をUpdateしてみました

動画開始16秒後、左上コンソール画面で変更をプライマリ(東京リージョン)に変更を実行してます。その後、右側上下2つのレプリカ側に伝搬していっているのが確認できます。以上です。

https://twitter.com/i/status/1368945583885488129

動画中に使用しているaws cliコマンド

# valueを確認
aws secretsmanager get-secret-value --secret-id <<<ARN>>> --region <<<REGION_CODE>>>--query "{Name:Name,SecureString:SecretString,VersionId:VersionId,CreatedDate:CreatedDate}

# valueを変更
aws secretsmanager update-secret --secret-id <<<ARN>>> --secret-string '{"<<<KEYNAME>>>":"<<<STRING>>>"}'

AWS lambda(Node.js)でオレオレ証明書(self-signed)を一時的に信頼してSSL通信を行う方法

この記事は2020年時点で検証した内容を記載しております。現時点でAWSのサービスUPDATE等により別の方式での回避策があるかもしれません。

はじめに

AWS lambdaのNode.js(https標準モジュール)で実装した、WEBサイトへhttpsのリクエストを投げる処理で、以下の2つのエラーが発生した際の対応についての記事です。 ※急いでいる方、ソースコードだけ見たい方はここから見ればOKです

スクリーンショット 2020-04-16 22.24.09.png スクリーンショット 2020-04-16 18.31.17.png

これ何

調べたところ、リクエスト先のWEBサーバから送出されているサーバ証明書に対してのnodejs内部での検証失敗のため生じたエラーでした。 2つのエラーの違いは、

👉2つのエラーは共に、Node.jsとして信頼1していないCA証明書にチェーンしていたため生じていました。

環境

  • AWS lambda
  • Node.js ランタイム12.x
  • 接続イメージ [AWS lambda]-->(WAN HTTP over SSL)-->[WEBサーバ]

対処案

3つ考えましたが、妥協点で私の環境では3つ目で実装しましたので以下にまとめます。

1.WEBサーバ側にちゃんとしたサーバ証明書2に変更してもらう

この対応ができたらこんな記事はいらない気もする。 自局署名の問題については、ネット上でも従前から議論されおり3、本記事をご覧になっている方でも既知のことと思います。WEBサーバ管理者に対しては、セキュリティの観点で懸念点を伝えてさしあげる程度にしました。

2.TLSハンドシェイクエラーを無視・無効にする

NODE_TLS_REJECT_UNAUTHORIZED環境変数に定義し、値を0とすれば検証自体がdisableになる模様。これは、curlでいうところの--insecureオプションと類似していますが、検証を全て無視するため有効期限やトラストアンカーとのチェーン等々を丸っとすっ飛ばす模様。(詳細は未検証のため割愛) https://nodejs.org/api/cli.html#cli_node_tls_reject_unauthorized_value

3.オレオレ証明書(self-signed)を一時的に信頼する

公式ドキュメントに書いてありました。 https://nodejs.org/api/tls.html#tls_tls_connect_options_callback 具体的には、通信先のWEBサーバのオレオレ証明書(サーバ証明書自体)ないしは、サーバ証明書のissuerとなっている現状信頼されていない自局CA証明書(pem形式)を取得し、https.requestのoptionにcaを追加するというものです。以下にサンプルを用いて実装例を示しています。

※今回の実装ではpemファイルの読み込みを、諸般の事情によりlambdaのみで完結したかったため、環境変数に事前に設定して、そこから読み込ませるという方法を使っています。(S3に入れて読み込むという方法もありかと思います。)

3-1.pemファイルを1行化する

環境変数にpemを入れるため、改行を¥nに置換します。

[work@localhost]$ awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' cacert.pem
-----BEGIN CERTIFICATE-----\nAIIDQjCCAiHCEQCQzvg6BX4eF(中略)v2wk3xtME7i8Jb2aUQH9vFVYuXUN2\nUO+j8l1OA4p1ew0kCsit2HOn\n-----END CERTIFICATE-----\n [work@localhost]$

余談ですが、当初は、pem形式って改行まで含んで形式であるということを理解しておらず、改行を単純に削除して環境変数に入れていたためエラーが発生して、ここで地味に悩みました。ちなみに、pemの改行は、Windows形式(CR+LF)、Unix形式(LF)どちらで良い模様なのでCRを削除後に置換している。4

3-2.AWS lamda環境変数の設定

上コマンドで表示された内容を環境変数にCA_PEMとして保存します。 スクリーンショット 2020-04-16 14.43.23.png

3-3. 実際のスクリプト(sample)

const https = require('https');

//ここで環境変数からcacertにPEMを読み込んでいる
var cacert = process.env['CA_PEM'].replace(/\\n/g, '\n');

exports.handler = (event, context) => {
    //caを追加してcacertを設定
    const options = {
      protocol: 'https:',
      host: 'example.com',
      path: '/index.html',
      port: 443,
      method: 'GET',
      timeout: 8000,
      ca: cacert,
      headers: {
        'User-Agent': 'AWS-lambda',
      }
    };
    
    let req =  https.request(options, (res) => {
      res.setEncoding('utf8');
      let body = '';
      res.on('data', (chunk) => {
        body += chunk;
      });
      res.on('end', () => {
        console.log(body);
      });
    });
    req.end();
}

3-4. エラー解消。取れました

Response:
null

Request ID:
"XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

Function Logs:
START RequestId: XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX Version: $LATEST
2020-04-16T14:26:29.930Z    XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX INFO
<!DOCTYPE html>
<html lang="jp">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Hello</title>
</head>
<body>
    This is test page ;>
</body>
</html>

END RequestId: XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
REPORT RequestId: XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Duration: 210.24 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 68 MB  

  1. Node.jsのSSL通信時のトラストアンカーってなんだろ?と思い調べた。https://github.com/nodejs/node/blob/bf7409e9740ce602b09e088aac70b7c817f5d27c/doc/guides/maintaining-root-certs.md 読んでみると、このソースに書いてあるよとのこと。Mozilla NSSのトラストアンカーと合わせているみたいですね、定期的にメンテはされている模様。ここに自己署名をここに入れるのは影響が大きそうです。

  2. Node.jsのトラストアンカー[^1]に含まれるCAに直接または間接的に署名されているサーバ証明書のこと。

  3. Qiitaですと、こちらの記事がとても参考になりました。オレオレ証明書を使いたがる人を例を用いて説得する

  4. 出典:https://stackoverflow.com/questions/57870914/how-to-create-a-single-line-x509-certificate-that-can-be-parsed-by-openssl-comma

【GoogleAppsScript】iPhoneウィジェットからワンタップでGmailを送る方法


注意

本記事で実装しているコード及び、レシピ、設定等は、セキュリティリスクを許容している勉強用のサンプルです。実運用される際は、各自でセキュリティ実装を行い、自己責任でお願いします🤲


image.GIF

TL;DR

  • oauth非対応のWEBクライアントからのGoogleAppsScript経由でのgmail送信を試みた
  • サーバ側(GAS)のサンプルコード
  • クライアント側(iOS ショートカットアプリ)のサンプルレシピ
  • 試行する際、サーバ側/クライアント側の環境変数設定を忘れずに!

目次

背景

サードパーティからのGmail送信が規制*1されていく中で、簡易的にGmail送信をできる方法を考えてみました。以下では、iOSのショートカットアプリ(旧 workflowアプリ)とGoogleAppsScript (以下、GAS)を使ってGmailでの送信を実装しています。

試行手順

GASとは/GASアカウント取得

  • GAS導入を丁寧に解説していただいている記事がございましたので、本記事では割愛させていただきます。

プロジェクトの作成

  • GASコンソールから、新規にプロジェクトを作成してください。(プロジェクト名はお好きに) 1.png

コードコピー

  • サンプルコード を新規プロジェクトのコード.gsにコピーしてください。(コード名はお好きに) 2.png

環境変数設定(スクリプトのプロパティ)

  • コード表示部の上、[ファイル]→[プロジェクトのプロパティ]→[スクリプトのプロパティ]
    • _DEST_ADDRESS:送信先のメールアドレス(サンプルコードでは、固定の宛先に送る仕様です)
    • _TOKEN:クライアント側(iOSショートカットアプリ)と共有するパスフレーズ(共有鍵)(パスフレーズは英数字記号を混在をオススメします)
  • 2つのパラメタを下記の様に設定します。 3.png

ウェブアプリケーションの公開

  • 公開範囲の設定を、リスク*3をご理解の上、 "全員(匿名ユーザを含む)"で公開にするとショートカットアプリからのAPI(HTTP(S) POSTリクエスト)を受けることができます。 4.png
  • 公開後、画面にURLが表示されるので、コピーして手元に残しておいてください。
  • 今回は実装までの最短手順を示しているため、全体公開にしてますが、本来であれば、Restlet Client等のテストツール使用し、検証さることを推奨します。

認証

  • 上記の公開範囲の設定の途中で以下のポップアップが表示される可能性があります。 5.png
  • これは、コード内部でMailApp.sendEmail使用してメール送信を実装しているため表示されています。
  • スクリプトからGoogleアカウントへメール関連の認可の可否が尋ねられるので、確認してください。*2 6.png

ショートカットアプリのレシピ作成

iOS側の環境変数設定

  • リマインダー"環境変数"リストを作成
  • 以下、2つのタイトルでタスクを作成し、それぞれのメモ欄にパラメタを設定ください
    • タイトル「gas_webhook2gmail_apikey」
    • タイトル「gas_webhook2gmail_url」
      • メモ欄:GASの公開時に表示されたURLを設定します
  • この2つ環境変数が他者に流出しますと、ご自分のメールアドレスの送信を不特定多数の第三者に悪用されてしまう可能性がありますので、厳格に管理ください

    準備完了

  • 以上で、サーバ/クライアントの準備は終わりました。ショートカットアプリからレシピをタップし、結果でsuccesと出ればメールが飛んでいるはずです。

解説

Webhook2Gmail.jpg

全体構成

  • トリガーは、iPhoneウィジェットのタップにより実行
  • ショートカットアプリにて、メッセージの入力、JSONリクエストの組立を行い、 GAS側の公開URLへHTTP(S)のPOSTリクエストで実施。
  • GAS側でJSONからパラメタ取得、ハッシュチェックを実施、Gmail送信apiをコール。
  • Gmailからスクリプトのプロパティで設定した送信先アドレスへメールが送信されます。

コード

  • PropertiesService.getScriptProperties().getProperty
  • プライベートキーをコードに書きたくなかったので、スクリプトのプロパティに変数として設定しておき、getすることでコードの公開時に手作業で消す煩雑な作業を無くしました。setコマンドもあるので、ちょっとしたパラメタはスプレッドシートでは、なくてもいいかもしれません。
  • doPost(e)
    • 本コードのメイン関数。GASのお作法としてfunction名をdoPostにすることで、POSTメソッドを受け取った際に、当該関数が呼び出される。仮引数eは、クライアントから渡されたオブジェクトを指す。doGetと記載するとGETメソッド時の処理を書ける。
  • jsonParse(e,parseName)
    • GASではPOSTで受け取ったオブジェクトをContent-Typeで判断せず、一律FileUploadクラスとして扱っているため、一度まとめてparamsの箱に格納し、その後対象パラメタに絞り取得している。
  • tokenCHK(auth)
    • JSONのauthパラメタと、サーバ側の現在日時と事前に設定したパスフレーズを足してハッシュ化し比較。これは、通信経路上で盗聴したリクエストを再送した、リプレイ攻撃対策として、現在時間をなんちゃってOTPとして扱いクライアント、サーバ双方で計算するようにしました。
  • toGmail(mailBody)
    • JSONのmailbodyパラメタから取得した値を仮引数として受けて、MailAppクラスを使いメール送信を実施している。今回のサンプルでは、送信先メールアドレスやメールタイトルは、固定にしていますが、実装次第では可変にすることもできると思います。

ショートカットレシピ

  • レシピを眺めれば日本語で書いてあるので、基本説明不要かと思いますが、サンプルコード同様に公開することを前提に書いていたのでプライベートキーについてはリマインダーを読み込むことで実現しています。

残課題

  • URLとパスフレーズの2つで認証としているが、URL自体は通信経路で盗聴されていれば、誰でも取得できるものなので、認証強度が低い。
  • 短時間の同一IPからの施行、連続認証失敗等の不正攻撃時特有の振る舞い検知の仕組みがない。

まとめ

サービスとしては車輪の再発明でしたが、個人的にJSON解析やAPIを全体公開をする際の留意する点などを考えることができたという意味で、勉強にはなりました。 方式を考えて行く中で、WEBAPIで実装すべきセキュリティ観点って意外と日本語でまとまってないなと感じました。広義ではAPIWEBサービスですので、参考にすべき資料はいっぱいあるのですが、、ジャストでこれというものがないという印象。(ググり力不足かもしれません)

余談

  • 今回クライアント側に使用した、iOSのショートカットアプリ、便利でいいのですがアプリ名が汎用的過ぎてググるのに苦労します。もっとユニークな名前を付けてほしかったです 笑
  • コードを書いた時間<ショートカットのレシピ作成時間<この記事の執筆時間
  • もっと記事をサクッと書けるようになりたい。。。

参考にさせていただいた記事

REST セキュリティに関するチートシート

Qitta - スプレッドシートで覚えるブロックチェーン |「もしかして渡した値」「入れ替わってる!?」

Google Apps ScriptのdoPostでJSONなパラメータのPOSTリクエストを受ける

Qitta - 【GoogleAppsScript】doPost のリクエストパラメータでHTTPヘッダを取得することはできない

GASへのPOSTリクエストの返り値の受け取り方

Google Apps Scriptをウェブアプリケーションとして公開する手順

Qitta - GASでのメール送信についてまとめてみる


1: workflow標準のレシピでも以前はGmail連携はできていましたが、左記の事情により現状連携ができなくなっているみたいですGoogle、個人情報へのサードパーティーアプリからのアクセス制限を強化

2:認可時に表示された(認証した)Googleアカウントを GASの送信元としてメールは送信します

3:ここでは、iOSのアプリからのアクセスを許容するため、公開範囲を全体にしています。多少のセキュリティ実装はあれど、ご自分のgmailを不特定多数がアクセスできるインターネット上に晒すことに繋がります。セキュリティリスク(不正送信、なりすまし等)のご理解の上、ご使用ください。

【GoogleAppsScript】実行可能API(Execution API)の初期設定でハマったので流れをメモする

概要

GoogleAppsScript(GAP)で書いたコードを外部から実行させようとGSPのスクリプトコンソールから[実行可能APIとして導入...]をクリックした際、以下のエラーが出て前に進められなくなった。
スクリーンショット 2019-06-09 11.31.09.png

ユーザが管理する Cloud Platform プロジェクトが必要です

結論

GoogleCloudPlatform(GCP)のプロジェクトを手動でGSPのプロジェクトで関連づける設定が未実施だったため上記のメッセージが出力していました。
※2019年4月8日 GAPとGCPの連携に仕様変更があり、以前だとGAPでのプロジェクト作成時に自動でGCP側のプロジェクトが紐づいていたが、今現在(2019/06/09)だとその機能が無効になっている。
https://developers.google.com/apps-script/guides/cloud-platform-projects

確認方法

  1. GAS側操作)外部公開したいコード(実行可能APIとして設定したいGASプロジェクト)のWebコンソール画面を開く
  2. GAS側操作)上段の[リソース]=>[Cloud Platform プロジェクト]を選択
  3. GAS側操作)以下画像と同じく、プロジェクト番号が空になっていることを確認
スクリーンショット 2019-06-09 11.59.23.png

この状態だと、GCP側のリソースや機能を連携して利用することができない状態になっています。つまり、本事象と合致している可能性があります。

設定方法

  1. GCP側操作)GCPよりAPIを公開する際に紐付けるプロジェクトを開く(GCPの初回登録やプロジェクトの作成方法は省略)
  2. GCP側操作)ダッシュボードより[プロジェクト情報]=>[プロジェクト番号]をコピー
  3. GAS側操作)GCP側で認証情報設定を完了させてください。という旨の表示が出る。
  4. GCP側操作)[APIとサービス]=>[認証情報]を選択
  5. スクリーンショット 2019-06-09 12.14.21.png
  6. GCP側操作)[認証情報]を参考記事等を拝見させていただきつつ設定
  7. GCP側操作)[OAuth同意画面]を[参考記事]参考記事等を拝見させていただきつつ設定
  8. GAS側操作)確認方法-3で表示したGAP側のフォームにプロジェクト番号を貼り付け、[プロジェクトを設定]をクリック
  9. スクリーンショット 2019-06-09 12.28.30.png
  10. GAS側操作)紐づいたら上記9のようにGCPのプロジェクト名が表示される
  11. GSPのスクリプトコンソールから[実行可能APIとして導入...]を実行した際のエラーは解消を確認ください

そろそろ、オープンAPIについて真剣に考えてみた。

<はじめに>

金融サービスの大衆化、Fintechを取り巻く環境は、この1年でかなり変わって来ていると下っ端の金融エンジニアでも感じる今日この頃。
また、本年6月には2年連続となる銀行法も改正され、各銀行にはオープンAPIの解放向けて努力義務が生じている現状もあり、今一度、関連する用語や、法案対応に向けた国内の動きについてまとめてみる。

あくまでも私はこう理解したというものですので、ご指摘等あれば是非にお願いします。

<わかっていること>

オープンAPIとOpenAPIとRestFulAPI

オープンAPI

ある企業が提供するAPIのうちサードパーティーがアクセス可能なAPIのことを指す言葉である。

WEB API

Application Programming Interfaceの略称で、ソフトウェア(システム)の一部を公開し、他のソフトウェア(システム)と共有できるインタフェース(及びその仕様書)を指す。RestFul、SOAPってものがありますが、Restfulが主流ということでここではあまり語りません。(RestはAPIを設計するための概念であり、SOAPは規格というレイヤの違いがある。以外あんまり分かってない)

OpenAPI

RESTful APIインターフェイスを記述するための標準フォーマットを定義するための仕様のことを指す。(オープンAPIとOpenAPIで意味が全く違うってのがややこしい)

銀行法の改定内容について

国会提出法案等 : 金融庁

銀行目線

電子決済等代行業者との連携及び協働に係る方針を公表しなければいけない

2018年3月までにそもそもオープンAPI対応するかどうか。
対応するのであれば、更新系API及び参照系APIのそれぞれにつき、導入の有無及びその理由、導入する場合には導入予定時期等を公表することが求められている。
(自らが公表したセキュリティ等に関する一定の基準を満たす電子決済等代行業者を恣意的に拒絶することはできない。)

Fintech事業者(電子決済等代行事業者)目線

電子決済等代行業者の登録制

(6か月間の登録猶予期間あり)詳しくは現状どこでも語られていない様子。
6ヶ月と言うことは2017年中には登録についてアナウンスが出るのか?
ここらへんは、認定電子決済等代行事業者協会*1あたりからアナウンスがでる?

ウェブ・スクレイピングに基づく事業活動を停止

改正法施行後2年間は、銀行との間の契約締結義務が猶予されるが(改正銀行法附則第2条第4項)、
この時期までに銀行との契約が締結できていなければ、停止しなければいけない。
(締結できてさえいれば、スクレイピングがNGと言う訳ではない)

銀行のオープンAPIについて

認証認可

API実行時の認証認可については、OAuth2.0がスタンダートとなっているが、
OAuthは認可のみを定義したフレームワークであり、認証部分については定義していないため、
OpenIDConnect等の認証プロトコルで整理されていく?と推測。
ちなみに、オープン API のあり方に関する検討会の1月時点*2では、

仕様の標準化に関連する論点については、本年度内を目途とする報告書の取り纏めまでに考え方を整理する予定。

との記載がありまだ不明確。

実装すべきAPIや電文規格について

・オープンAPIはRestFulであるべきらしい。
APIはある程度のグループに分けてユーザに認可をさせるべきらしい。

どの文章を見てもやはり、shouldであり。msutな実装と言うものは見当たらなかった。
イメージとしては、とりあえず責任分解だけしっかりして自己責任でよろしくと言う感じが否めない。

オープンAPIの収益性について

どの書類にも具体的には触れられていない様子。
義務or努力義務なので、銀行は開示せざるを得ないと言う状況になって開示すると言う流れなのだろう。

<関連団体/ワーキンググループから出ている書類や議事録について>

金融庁
  金融審議会の金融制度ワーキング・グループ
http://www.fsa.go.jp/singi/singi_kinyu/tosin/20161227-1.html#

・Fintech協会
  認定電子決済等代行事業者協会
https://www.fintechjapan.org/resources/Documents/faj20170303.pdf

全国銀行協会
  オープンAPIのあり方に関する検討会

・FISC
  金融機関におけるFinTechに関する有識者検討会

経済産業省
  FinTechビジョン*3

・政府(官邸)
  日本未来投資戦略2017*4

・一般社団法人 金融ISAC
  FinTechセキュリティWG

【Qiita】curlを使ってネットワークの時間帯コンディションを妄想する

ベンチツールとか入れられない環境でネットワークの遅延調査をすることになった。
curlって初めて使ったけどftpとかpostメソッドとか対応していて便利なんですね。
ってことでQiitaに覚え書きしておきました。

qiita.com

Qiitaとブログの使い分けどうすればいいんだろ。
あ、あとGitHubか。。。うーん。