日曜エンジニア

金融担当SEの仕事・趣味のメモ置き場です。

【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か。。。うーん。

エセインフラエンジニアの焦り(訳 qpstudy 2016.04 響け!アラートコール! の参加しました)

2016.04.23@西新宿ニフティさんで開催された、qpstudyの勉強会に参加しました。

f:id:ls-ltr:20160506110725j:plain

はじめに

勉強会のwarp upの通り、ブログを書くまでが勉強会!ということで、各セッションで感じたことを、私の焦りを書いてみます。覚書みたいになり、読み辛いかと思いますが、よろしくお願いします。
あーこういう残念なエンジニアもいるんだなと知っていただければ幸いです。

エセインフラエンジニアの背景

  • 20代男性
  • 金融関係SIer
  • リリースしてドキュメント納品しておしまいではなく、保守まで一括して受託している会社で働いています
  • 社内ポジションはインフラ担当(Dev&保守運用)
  • Devでの自担当範囲は、要件定義から詳細設計までと試験から移行。インフラ担当のため、基本ベンダさんの進捗管理がメインとなっているのが実情
  • 保守運用範囲での自担当範囲は、顧客からの照会、定期的な各種リソース状況の評価、障害発生時の切り分け調査
  • 夜勤監視はしてません、夜に起こされる系男子
  • 業務でプログラミングしたことない(必要となればbashDOSコマンドでbatを少々レベル)
  • 未だにベンダ営業に電話しちゃうタイプの人間
  • 懇親会は残念ながら不参加勢
  • ると (@karoot) | Twitterの人

発表を聴いて

その1「インフラ監視の今後を考える」
speakerdeck.com
その2「Re: 運用に自動化を求めるのは間違っているだろうか」

www.slideshare.net

勉強会の経験が浅い私には、全体的にモヤモヤしているなというのを感じました。(後に控えたグループディスカッションのためでしょうか)
「なぜ監視をするのか?」の問いかけに、「しないといけないから。お客さんの要望でしょ。」と反射的に思いましたが、後々のディスカッションの中で監視するコスト<障害による損失だから監視をしているという当たり前のことに気づきました。自社内でもランニングコストを安くすませるために、監視をしていないシステム、松竹梅で監視のレベルを業務要件に応じて提案&実装しているシステムが身近にもありました。(他の人もおっしゃっていましたが、監視レベルの松竹梅の段付は、システム担当のエンジニアやプロマネの経験則に依存していることが多いかもしれません)

運用自動化については、私の携わっている金融システムでも徐々にきています。最近だと、パニックからのOS自動再起動復旧→サービス稼働確認→商用利用開始などは自動化の仕組みを構築しました。(私達の説明が行き届いていないのもあり、お客様システム担当は自動より手堅い実績のある手動でというと流れが残っているのも事実です。)

脱・刺身タンポポ、脱・写経文化という中で、こんな*1
記事を書いてしまう、また要点をサラサラと書けてしまう自分の業務は、世の中から数十年遅れていると痛感しました。

グループディスカッション

・他の班にもちらほらいましたが、金融系って精神的にも物理的にも独自の進化を遂げているなと痛感しました。
・どこかのチームで前提として発表してましたが、話し合う前にお互いの監視対象のシステムの概要、規模だけ意識合わせすればよかったと。
・運用/開発の温度感の問題はどこも陥りがち。
・自動化は手段でしかない。目的の明確化、メリット感をアプローチできる人が社内にエバンジェリスト的存在?が必要

焦り

私が業務でしていることは開発メインだと思ってたけど、半分は世の中的に言う運用に片足を突っ込んでいて、物理的にも精神的にも現在閉ざされた環境だからこそ生きていけるエンジニアなのではと認識しました。
今後、金融業界のfintechによるオープン化、PaaSやdockerなどを活用したDevOpsという新しいアプローチ、インフラの家畜化(リソース仮想化に伴う死んだサービスは放置し新たに作る風潮)により、閉ざされた環境が崩壊。このままだと、私の領域は自動化され、お給料はなくなり死に絶える。私の会社が体制が(笑)とか、金融だから(笑)と飲み会の席で愚痴を言っている場合じゃない。

インフラが変革してきている今、オン/オフで惰性で吸収してきた様々な技術ノウハウを一度見つめ直し、早めに方向性を決めていかないといけない。

総括

拙い文章を最後まで読んでいただき、ありがとうございました。私にとって、社外の利害関係のない方との初グループディスカッションでしたが、上記の様な焦りを感じることができ、とても有意義半日でした。
またどこかでお会いする際・本Blogコメントで、ご指導のほどよろしくお願いします。

NextAction

  • デプロイを実際にしてみる
  • 人間でしかできないことを武器にする(メトリクス、予兆検知)
  • 得意なネットワーク範囲を深くする(SSL/TLS,SMTP,DNS)
  • AWS/Azureの環境構築
  • SlackAPIへ自宅のサーバやAWS/Azureから連携

ご参考

本記事を書く中で拝読させていただきました、素敵な記事の紹介をさせていただきます。中間管理職的なインフラエンジニア?な人、是非読んでみてください、とてもいい刺激になると思います:-))

インフラエンジニア(狭義)は死んだ - YAPC::Asia Tokyo 2014
インフラエンジニアの幸福論 · the world as code
[インフラ] インフラエンジニアの将来は明るいのか:その1 [アプリ] – oshiire*BLOG
[インフラ] インフラエンジニアの将来は明るいのか:その2 [アプリ] – oshiire*BLOG

【新米SEさんへ】商用作業でココを気をつけて

医療ミスでなくても、人は○せる。金で人は死ぬ。我々がやっていることはそういうことだ。by 課長
課長が先輩をしばいていた指導していた時のお言葉です
 

本題、私は入社してから4年間、金融関連システムの商用オペレーション*1に従事してました。

最近は指導もしてるのですが、後輩と話す時に、よく言っていることをまとめてみました。1〜2年目の新米SEさん、指導する方の参考に少しでもなれば幸いです。
 
金融ということで厳しいルールが多いので、読者の皆さまにフィットするか不安ですが、、、大は小を兼ねる。規則は後から締めるのは辛い、緩めるのは一瞬。ということで、ご一読いただければ幸いです!

 はじめに

本記事には、再起動やインストールなどを勧めるような記載がありますが、各自職場、商用環境の規則を必ず確認してください。あくまでも商用に挑む時の参考、チェック観点としてご覧ください。
また、他に観点があればコメント等いただければ追記いたしますのでご指摘・コメントお待ちしております。

f:id:ls-ltr:20160411204306j:plain

まずは考え方から!

心構え編

  • トラブルでも商用で自分の慣れてない操作は行わない

どんなに準備してもトラブルは起きます。トラブルが起きたときいつもは細かい上司が、なんでもいいから解決して!と手順外のオペレーションを上司に要求されるかもしれません。そんな時、なるべく知っているコマンドで、解決するようにしましょう。自信がない時は検証環境で試す時間をください。と頼む勇気も必要です。

  • 作業の証拠を残す(手順を作る時は残すことを明記する)

昨今、システム担当者による情報流出なども疑われる時代。自分が実施した内容が妥当であることを保証出来るようにしましょう。また、手順の作成する際、適当な場所にdateコマンド等を入れておくと、証跡から作業所要時間なども後から確認することができます。

  • 悪いニュースほど早く上げる

結果として大丈夫だろうなと思っとも、想定外のコマンド結果やメッセージは、悩んだり調査するよりまず報告。上司へ余計な心配をさせてしまうと思うかもしれませんが、その心配をするのが管理職の仕事、商用の障害の検知が遅れるよりマシです。

  • 作業は手順に従う

大前提ですが、手順に従いましょう。コマンド操作は、コピペの癖をつけましょう、せっかくの手順書も商用作業中の打ち損じでトラブルが起きたら元も子もありません。また、手順書作成の際、操作だけでなく想定結果を画像や標準出力を記載しましょう。

例)ディレクトリ移動手順

# cd /tmp/

# pwd

- pwdコマンドの結果、/tmpとターミナルへ標準出力で表示されること。

  • 手順は必ず検証環境で実施する

商用環境用の手順書を作る時は直接手順書を手打ちするのではなく、検証環境で実施したログからコピーして手順書を作りましょう。(コマンド練習などのお試しは検証環境等々で実施しましょう。)

 

f:id:ls-ltr:20160411205926j:plain

準備が全て!

商用作業前準備編

  • 作業用端末が別のチームにロックされてないか確認

(各自端末を商用環境に都度持ち込んでいる方は除く)既設共用端末を利用する際に、別作業とブッキングしており、端末がユーザロックされていて作業が開始できない。なんてことがないように事前に見に行きましょう。

  • 作業用端末は使い始める前に再起動

サーバルームが近くにない限り、windowsOSの端末を使ってssh、rdp、sftp等々を使って作業対象サーバへ接続を試みるのが一般的なのかなと思います。

もし、再起動をしてないで端末を酷使していると、エクセルやらエクスプローラが固まることも多いです。念のため、できることなら再起動してしまいましょう。
  • 手順書が開けるか確認する

実体験ですが、転送中にファイルが破損することはあります。いざ作業を開始となってエクセルがでファイルを開こうとしたら、”破損しています。開けません。”とか洒落になりません。破損だとエクスプローラで見ても容量は本物と同じだったりするので、面倒ですがエクセルで開いてみましょう。また、エクセルのバージョンが合わず開かないなどありえます。(エクセル以外のファイルでも同様です。)

  • 手順書で必要なそのソフトは商用端末にある?

この端末は〜〜ってソフトないのか!とか、当日作業中に気づくのはやめましょう。(事前確認しましょう。手順を引き継いだけだから、、、と言いたいのなら、依頼元にどの端末でやればいいのかまで指定を要求しましょう。)

  • 諸手続き、ファイル転送時間も考慮する

作業開始直前に、6Gbyte越えのインストーラを手元に用意しても、物理的にもネットワーク的にも遠方にあるサーバには、インストール作業は開始できません。ファイル転送は事前にやりましょう。*2また、商用環境へ入室、入館する時間は考慮し、行動してますか?

  • 個人情報の定義を理解する

採取した情報に個人情報が入ってないと言い切れますか?間違えてインシデント対応でベンダに渡してしまい、後から監査に刺されるとか、場合によっては取り返しがつかない時もあるのでしっかり理解して作業へ臨みましょう。

 

f:id:ls-ltr:20160411210232j:plain

いよいよ本番作業!!

商用作業編

  • GUIよりコマンドで

伝わりにくいので例を挙げると。

  1. スタートメニューを左クリック→左下電源→プルダウンから再起動を選択→実行
  2. ctrl+r→cmd→shutdown /r /t 0
上記は簡単にwindowsの再起動手順を示したものです。この場合、私であれば2.の手順を選びます。理由としては、コピペで作業ができる。作業証拠が簡単に残せる。(ターミナルのログ出力機能を利用)
一番大きいのは、誤操作をした時に致命傷になりにくい。という点です。もし、1.の手順の場合、プルダウンを1つずらしてしまうと、電源断となります。コマンドであれば、手打ちしてしまって打ち損じだとしても、ミスの大半はスペルミスとなり実行エラーとなるため影響はない少ないです。
  • ファイルコピーは中身以外も気をつけて

ファイル権限、タイムスタンプなどOS間で引き継がれない項目orコピー時に変わる項目が存在します。異なるサーバ等で資源を管理したりする場合は圧縮等の回避方法を検討ください。

  • 作業中の決定的な部分はしっかり

理想は手順書に従いコマンドやマウス操作を1コマンド、1クリック単位で確認したいです。が、往々にしてそんなに時間は与えられません。そのため、システム変更コマンドや操作の のタイミングの直前を特に意識してオペレーションしましょう。(システム変更のタイミングを理解するためにも、検証で事前のお試しをオススメします)

最後に

あたりまえですが、リリースした後は運用部門だけで回るように開発上流工程で運用設計するのが一番だと思います!開発部門目指せノータッチ!共に頑張りましょう。
応援中!!↓
#qpstudy 響け!アラートコール!

備考

ご参考にですが、私の環境は以下の通りです。

*1:開発から引継を受けた運用部門のモノホンオペレータさんではないです。緊急デプロイ作業、セキュリティインシデントミドルウェアの更新や突発のインシデント調査で開発部隊が商用対応をする事を指しています

*2:転送で使用回線の帯域切迫に留意してください

【追記有(2016.04.22)】Windowsが遂にSymantecG1ルートを捨てるらしい

f:id:ls-ltr:20160411204843j:plain
本記事は2016年3月28日23時(JST)時点で調べた情報です。(一部更新してます)
最新情報等については必要に応じ、各業者にお問い合わせください。

【2016.04.22 追記開始】
当初4月19日に予定していたルート証明書更新プログラムですが、以下の通り延期となったみたいです。中止理由はわかりませんが、延期に関係なくクロスルートを使われている方は停止を引き続き検討すべきだと思います。

本日、マイクロソフト社より、日本時間4月19日または4月20日に予定されていたルート証明書情報の更新を延期する旨の通知を受領いたしました。延期後の実施日時などの詳細は、マイクロソフト社より情報を得られ次第、追加でご案内させていただきます。

Symantecサイトより抜粋
【2016.04.22 追記終了】


実は今年の1月にも同様の*1事象はあったのですが*2Microsoftが有名なレガシーなルート証明書の利用停止に向けて乗り出した模様です。

今回Symantecが発表したG1ルート証明書は、かなり前のものなのですが、有名な企業サイトでも現在もなお利用しているクロスルート*3証明書のに影響を及ぼすものなので書いてみました。

下記Symantec社のリンクを読めば、より詳細な内容が書いてありますが、噛み砕いた感じで書いてみましたので暇な方はどうぞ。
(本文章には私の知識不足のため、誤解を招く表現があるかと思います、ご指摘のほどお願いいたします。)

knowledge.symantec.com

影響開始日*4

2016年4月19日(火) 米国時間
2016年4月19日(火) または20日(水)日本時間

G1ルート証明書とは

Symantec社の自己署名証明書です。正式な名前は以下の表の通りです。
所謂、ルート証明書として世界中の広いプラットフォームに工場出荷の時点で入っています。
また、G1ルート証明書は鍵長の短さなどのセキュリティ上の理由から、
2015年12月末をもって新しい証明書への署名を中止(retired)していました。
今回のMS社の本対応は、Symantec社のretiredを受けてってのもあるかもですね。

f:id:ls-ltr:20160329002647p:plain
https://www.jp.websecurity.symantec.com/developer/step01.htmlから抜粋

影響内容

上記Symantec社のリンクにある、以下のタイトルのPDFがわかりやすかったです。
[補足資料] 2016年4月(予定)のマイクロソフト社のルート証明書情報更新の影響と対策に関するご案内について.pdf

端的に言うと、WindowsOSに入っているG1ルート証明書のサーバ認証オプションをDisable(ブラウザとサーバ間のSSL通信の認証としては利用させない)にするそうです。
そのため、G1ルート証明書に連鎖(チェイン)するクロスルート証明書がサーバから落ちてきた際に、検証を行おうとしてもサーバ認証ではG1ルート証明書は使えないため、SSL通信(ブラウザのURLでhttps://で始まるもの)が失敗し、エラー画面が出てしまう可能性があります。

影響先

これもPDFがわかりやすいです。
一般的に一番利用されているサーバ認証はブラウザとインターネットを経由したWEBサーバとのhttps通信だと思い込んで、簡単に抜粋してみる。

サーバ側

クロスルート証明書を送出しているか確認してみてください。
個人的に推しているSSLLABSさんを利用させてもらって、G1にチェインしている証明書をクライアント側に送っているかを確認する流れを書いておきます。

https://www.ssllabs.com/index.htmlへアクセス
右上のTestYourSeverを選択
Hostname:欄に調べたいWEBサイトのFQDNを入力し、submit
(2〜3分待つと結果が表示されると思います)
Additional CertificatesにG1に証明されている証明書が落ちてきているかを確認
 こんな風にIssuerって欄に書かれていたらそうです。
 Issuer VeriSign, Inc. / Class 3 Public Primary Certification Authority

クライアント側

SymantecG5ルート証明書が入っていないパソコン。
つまり、レガシーなパソコンです。(WindowsXP以前、WindowsUpdateなどを定期的に行ってないと怪しいです。)

上記のサーバ側とクライアント側と書いた条件に対してANDでヒットしそうだと思った場合、
2016年4月19日を境に、ブラウザで警告が出る可能性がありますので、ユーザは最新のSymantecG5ルート証明書のインストールをお願いします。
また、企業の皆さんは案内の準備をしたほうがいいかもですね。

MS社側告知

現在ではまだないみたいですね。
aka.ms

*1:コメントにてご指摘いただき、類似→同様という表現に変更しました。ありがとうございます。

*2:SMIME署名機能をG1証明書のオプションから OFFにする設定を配布していた。https://knowledge.symantec.com/jp/support/securemail-id-support/index?page=content&id=ALERT1958&actp=LIST&viewlocale=ja_JP

*3:クロスルートとは https://jp.globalsign.com/support/faq/431.html

*4:インターネットを介しての配布なので影響が始まる時間と考えた方が良い。実際は、ユーザ次第。